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

Matheus — Tue, 15 Sep 2026 00:17:51 +0000

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.

DEV Community: Matheus

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

O custo cognitivo da tradução mental

O mesmo termo, significados diferentes: o perigo das God Classes

Conclusão