Por que o seu código deveria falar a mesma língua do seu negócio (e não do seu framework)

Quando você modela os métodos de uma classe chamada CheckingAccount , o que você escreve? get_current_balance() , check_pending_transactions() e approve_limit_increase() ? Isso pode soar natural enquanto você está imerso na IDE. Mas tente explicar para um gerente de produto ou analista de operações que um bug crítico está na função is_bank_ticket_paid() . Ou pior: observe a cara deles durante uma daily, planning ou review técnica tentando decifrar o jargão que a engenharia inventou para representar processos que eles operam há anos. Parece detalhe estético, mas a distância entre os termos do negócio e a sintaxe do código cobra juros altos ao longo do tempo. O custo cognitivo da tradução mental Pense no seguinte cenário: em uma reunião de refinamento sobre fluxo de concessão de crédito, os especialistas de domínio usam termos como aprovar crédito, checar limites e enquadramento. Enquanto isso, a engenharia passa a reunião inteira fazendo mapeamento mental: - "Aprovar crédito" vira approve_customer_credit() . - "Checar limites" vira check_account_credit_limits() . - "Enquadramento" vira check_classification() . Cada camada de tradução adiciona atrito, gera ruído e abre margem para bugs conceituais (aqueles em que o código roda perfeitamente, mas faz a coisa errada para a regra de negócio). Não faz mais sentido todo mundo falar exatamente a mesma língua? É aqui que a Linguagem Ubíqua (Ubiquitous Language) do Domain-Driven Design entra. Ela remove o intermediário: os termos usados no código devem refletir o vocabulário real do domínio. Se você está em uma cooperativa de crédito brasileira, não faz sentido ter Customer e active_member() se o domínio fala Associado e associado_ativo . Atenção: Linguagem ubíqua não é apenas pegar o jargão solto da área de negócios e jogar no código sem critério. É uma via de mão dupla. Muitas vezes o próprio time de negócio usa termos ambíguos ou inconsistentes. Cabe à engenharia investigar: O que define, formalmente, um associado ativo? O que acontece exatamente na etapa de enquadramento? Quando o time técnico desafia as definições e o negócio entrega termos precisos, o modelo final é construído de forma colaborativa e rigorosa. O mesmo termo, significados diferentes: o perigo das God Classes Dentro do DDD, a Linguagem Ubíqua ganha tração de verdade quando respeita Contextos Delimitados (Bounded Contexts). O erro clássico aqui é tentar criar uma entidade global para reaproveitar tudo e gerar uma clássica God Class. Imagine uma cooperativa financeira com três contextos claros: Seguro, Crédito e Investimento. Por mais que o associado físico seja o mesmo CPF, para o sistema ele representa papéis completamente distintos: - No Crédito: importam renda, capacidade de endividamento e score. - No Seguro: importam histórico de saúde, apólices ativas e perfil de risco do bem. - No Investimento: importam perfil de investidor (suitability), patrimônio alocado e liquidez desejada. Faz sentido ter uma única entidade Associado com dezenas de métodos e atributos acumulados, sendo que cada contexto vai consumir apenas uma fração deles? Obviamente não. graph TD A[Associado\nPessoa no mundo real] --> B[Contexto Seguro\nSegurado] A --> C[Contexto Crédito\nTomador] A --> D[Contexto Investimentos\nInvestidor] Em vez de forçar uma entidade genérica em todos os módulos, a linguagem ubíqua deve refletir o contexto específico: - No contexto de seguro, você modela Segurado . - No contexto de crédito, você modela Tomador . - No contexto de investimentos, você modela Investidor . Cada classe encapsula apenas o comportamento e os dados estritamente necessários para a sua fronteira. Mesmo que alguns dados cadastrais básicos se repitam na persistência, o modelo conceitual permanece limpo, desacoplado e imune a alterações em cascata - mexer em uma regra de apólice não corre o risco de quebrar o cálculo de score de crédito. Conclusão Adotar uma linguagem ubíqua legítima não é capricho de nomenclatura ou pedantismo de arquiteto. É uma decisão que encurta o ciclo de feedback entre quem cria a regra e quem a implementa, reduz dependência de reuniões intermináveis de alinhamento e protege a arquitetura contra acoplamentos desnecessários. O código deixa de ser um labirinto de abstrações técnicas e passa a ser a documentação viva do próprio negócio. Top comments (0)