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.
