Blog

Eu sou fã do Donald Knuth. Li os livros dele. Aprendi com ele. Ainda aprendo. Se ele fala, eu escuto. Se ele fala sobre IA, eu também escuto.

Knuth é o autor de “The Art of Computer Programming”. Para muita gente, inclusive para mim, é uma das obras mais importantes já escritas sobre computação. Não é livro de moda. É livro de fundamento. Gerações de programadores aprenderam a pensar com ele.

Esses dias ele publicou um pequeno relato contando uma história curiosa. Enquanto escrevia material para um novo volume do TAOCP, ele estava trabalhando em um problema de combinatória. Não era exercício didático. Era problema de pesquisa. Daqueles que parecem simples de enunciar, mas dão trabalho de verdade para resolver.

Ele vinha explorando o espaço de soluções havia semanas. Um colega resolveu pedir ajuda para o Claude, o modelo de IA da Anthropic.

O modelo não respondeu com um chute. Reformulou o problema, escreveu programas para explorar hipóteses, testou caminhos, descartou o que não funcionava e seguiu procurando até encontrar uma construção geral que resolve o caso para todos os valores ímpares do parâmetro.

Isso não é geração de texto. É exploração computacional de um problema matemático.

Knuth abre o texto com algo que diz muito. Ele escreve que talvez precise revisar suas opiniões sobre IA generativa.

Depois ele faz o que matemáticos fazem. Reconstrói a lógica da solução e apresenta uma prova formal de que a construção funciona.

Ou seja, não foi truque. Nem palpite sortudo. Foi exploração sistemática de um problema matemático real.

Mesmo assim, ainda tem gente dizendo que IA só resolve código trivial.

Oseias 12 relembra a história de Jacó, aquele de quem nasceu o próprio Israel. Antes de existir uma nação, existiu um homem. E a história desse homem ajuda a entender o povo que veio depois.

Jacó não foi um patriarca perfeito. Sua história começou marcada pela conduta nem sempre honesta. Mas em determinado momento algo mudou. Jacó lutou com Deus, confrontou sua própria história e saiu daquele encontro transformado. Foi ali que Jacó se tornou Israel.

O contraste com o povo do tempo de Oseias é evidente. Enquanto Jacó passou pela transformação, a nação parecia repetir apenas a parte antiga da história, antes do duelo.

O capítulo fala de comércio injusto e balanças desonestas. Prosperidade construída sobre astúcia. Como se habilidade para negociar fosse suficiente.

O texto deixa claro que não existe separação entre espiritualidade e vida prática. O problema espiritual aparece nas relações, nos negócios e nas decisões diárias.

A balança injusta não é apenas um erro econômico. É reflexo de um coração desalinhado.

A história de Jacó aparece então como espelho. Ele também tentou garantir a vida pela astúcia. Mas em algum momento parou de fugir e entrou na luta.

E foi nesse confronto com Deus que veio a transformação.

Oseias 12 sugere que o mesmo caminho continua aberto. A luta nunca foi o problema. O problema é fugir dela.

Porque é nesse encontro que o homem deixa de viver apenas pela astúcia de Jacó e começa, finalmente, a viver como Israel.

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.