Nem todo projeto de TI é adequado para DDD. Concordo.

Há sistemas cuja complexidade está na engenharia, não no domínio. Compiladores, bancos de dados, motores estatísticos. Nesses casos, o desafio central é técnico.

Agora, outro argumento que sempre aparece: “Se é só CRUD, não faz sentido usar DDD.” Com esse, eu não concordo tão facilmente.

Foi exatamente essa discussão que tive com meus alunos em um workshop recente. E ela expõe um erro de critério que condena sistemas com potencial de riqueza à anemia.

Quando alguém diz “é só CRUD”, está olhando para a interface. Uma tela, alguns campos, um botão de salvar. É um critério visual.

Mas arquitetura não se decide pela aparência da tela. Se decide pela natureza das mudanças.

A pergunta correta não é “quais campos precisamos?”, mas “quais são os motivos que levam esses dados a mudar?”.

Entender esses motivos permite desenhar um ciclo de atualização saudável. Modelar transições, não apenas estados.

Um cadastro de funcionários com salários ilustra bem.

Salário não muda ao sabor de um clique. Em acordos coletivos, a movimentação acontece em lote. Em promoções, segue critérios.

Se você modela apenas como “editar salário”, organiza o sistema em torno da operação técnica, não do processo que justifica a mudança.

CRUD organiza software por operação. Domínio organiza software por significado.

CRUD pensa em registro isolado. Domínio pensa em transição de estado e evento que dispara consequência.

E esse entendimento começa ao questionar o motivo da mudança em cada campo.

Nome muda por casamento ou decisão judicial. Salário muda por promoção ou acordo coletivo. Cargo muda por reestruturação. Cada campo carrega uma história possível.

Quando você modela a história, o sistema ganha estrutura. Quando modela só o campo, nasce anêmico.

É assim que surgem eventos de domínio.

“SalárioReajustadoPorDissidio”.

“FuncionarioPromovido”.

“NomeAlteradoPorDecisaoJudicial”.

Eles dão semântica ao que ocorre. Muito diferente de um espião no banco que grita quando uma coluna muda.

O banco enxerga alteração. O domínio enxerga transformação com contexto.

Aceitar cedo demais que “é só CRUD” é uma decisão infeliz.

Você estrutura o sistema em torno de operações técnicas. Quando surgem reajustes coletivos, histórico, auditoria ou novas regras, o modelo começa a ranger.

A lógica se espalha. A manutenção encarece. O usuário sente fricção.

Não é o tamanho do sistema que define a necessidade de DDD. É a natureza das suas mudanças.

Se há história, há domínio. E onde há domínio, reduzir tudo a update de campo é abrir mão de estrutura antes mesmo de começar.