DDD não é coisa de dev (e a IA tornou isso urgente)

Neste artigo · 7 seções

1. o modelo não é artefato de dev
2. quem desenha o time desenha o modelo
3. core é decisão de board, não de encanamento
4. a linguagem é a invenção
5. e a IA tornou isso urgente
6. o que sobra escasso
7. Insights & Takeaways

Toda vez que DDD entra numa reunião de negócio, acontece a mesma coisa. Produto e liderança recostam na cadeira. "Parte técnica." Jargão de dev, capricho de arquiteto. E a conversa segue sem eles.

É o mesmo reflexo que virou piada num artigo anterior desta série, o de fundamentos: na entrevista, todo candidato recita "linguagem ubíqua, bounded context", tudo no lugar certo, e seis meses depois o repositório não tem uma fronteira de domínio à vista. Recita na sala. No git, não aplica. Só que, com DDD, tem um agravante: quem mais precisava entender nem estava na sala.

Porque a premissa que abre o DDD não é uma frase técnica. É uma frase sobre o seu negócio. Eric Evans, na abertura do livro azul, crava: "a complexidade mais significativa de muitas aplicações não é técnica. Está no próprio domínio, na atividade ou negócio do usuário" (no original, "the most significant complexity of many applications is not technical. It is in the domain itself, the activity or business of the user."). Lê com olho de quem decide. Se a complexidade que quebra o produto é do negócio, e não do código, deixá-la inteira na mão da engenharia é uma decisão de risco. Tomada, quase sempre, por omissão.

Prometi em Produto não é uma esteira de datas que a complexidade que quebra o produto merecia um artigo inteiro. Aqui está. A tese é curta: DDD resolve complexidade no lugar certo, o domínio. Linguagem ubíqua e bounded context não são decisões de implementação; são decisões de negócio, e produto e liderança precisam delas tanto quanto a engenharia. Com IA no circuito, isso deixou de ser refinamento de arquiteto e virou a linha que separa gerar a coisa certa de gerar lixo plausível.

o modelo não é artefato de dev

Tem uma inversão de responsabilidade que o negócio quase nunca enxerga. Quando o especialista de domínio não entende o modelo, a conclusão automática é "modelo é coisa técnica, o negócio não precisa entender". Evans diz o oposto: "Se especialistas de domínio sofisticados não entendem o modelo, há algo errado com o modelo" (no original, "If sophisticated domain experts don't understand the model, there is something wrong with the model."). Modelo incompreensível pro negócio não é sofisticação. É defeito.

E tem uma fronteira que ele proíbe de existir. Não a fronteira entre módulos, que é natural. A fronteira de linguagem entre quem entende o negócio e quem escreve o código. Várias linguagens podem coexistir num sistema; essa divisão específica, não. Quando os dois lados falam línguas diferentes e alguém traduz no meio, o conhecimento vaza na tradução.

Dev que modela sozinho inventa abstração falsa. Evans conta um caso do próprio time, constrangedor de tão comum. Eles criaram um conceito, "loan investment", achando que era termo do mercado bancário. Os especialistas do domínio repetiam, reunião após reunião, que não entendiam aquilo, e deferiam ao "conhecimento de software" do time. O conceito não existia no negócio. Era invenção dos devs, entendimento incompleto vestido de tecnicalidade pra ninguém questionar. É o que você compra: uma abstração que o negócio não contesta porque nem entende.

quem desenha o time desenha o modelo

Se o modelo é do negócio, a fronteira dele também é. E fronteira tem nome no DDD: bounded context. O erro clássico é tratar isso como detalhe de design interno. É decisão de organização, e das grandes.

Evans conta outro caso, e esse custa dinheiro visível. Dois times usavam a mesma palavra, "Charge", com dois modelos diferentes na cabeça, sem saber. Cada um construiu o seu, coerente por dentro. Quando juntaram o código sem resolver a contradição, deu no previsível: "Quando o código deles foi combinado sem resolver essas contradições, o resultado foi software não confiável" (no original, "When their code was combined without resolving these contradictions, the result was unreliable software."). Mesma palavra, dois significados, ninguém com autoridade pra dizer qual valia. Não é bug de implementação. É fronteira de negócio que ninguém desenhou.

Aí vem a frase que devia estar na mesa de todo diretor: "Um CONTEXT MAP está na sobreposição entre gestão de projeto e design de software. O curso natural dos eventos é que as fronteiras sigam os contornos da organização dos times" (no original, "A CONTEXT MAP is in the overlap between project management and software design. The natural course of events is for the boundaries to follow the contours of team organization."). Lê como Conway, porque é Conway. Quem desenha o organograma desenha o modelo, querendo ou não. Separou dois times sem alinhar a linguagem? Criou dois modelos que vão colidir, e a colisão vira "software não confiável" meses depois, longe da decisão que a causou.

Folclore de comunidade? O Accelerate, a maior pesquisa sobre entrega de software que existe, recomenda o mesmo pelo nome: "Abordagens arquiteturais que habilitam essa estratégia incluem o uso de bounded contexts e APIs como forma de desacoplar grandes domínios em unidades menores e mais fracamente acopladas" (no original, "Architectural approaches that enable this strategy include the use of bounded contexts and APIs as a way to decouple large domains into smaller, more loosely coupled units."). O suposto "conceito de dev" aparece na maior base empírica da área como fundamento de throughput e estabilidade, não como preciosismo de arquiteto.

core é decisão de board, não de encanamento

Agora a parte que mais dói, porque é alocação de gente, e alocação de gente é decisão de quem manda. Evans não deixa ambíguo: "Aplique o melhor talento ao CORE DOMAIN, e recrute de acordo" (no original, "Apply top talent to the CORE DOMAIN, and recruit accordingly."). Core domain é a parte do modelo que diferencia a sua empresa das outras. É o motor. E o anti-padrão que ele descreve você comete sem perceber.

Os devs mais habilidosos gravitam pra infraestrutura técnica e pros problemas bem definidos. O framework novo. A mensageria. O pipeline. Enquanto isso, "o núcleo especializado, a parte do modelo que realmente diferencia a aplicação... tipicamente acaba sendo montado por desenvolvedores menos habilidosos que... programam feature a feature sem extrair nenhum poder conceitual do modelo" (no original, "The specialized core, that part of the model that really differentiates the application... typically ends up being put together by less skilled developers who... code feature-by-feature without drawing on any conceptual power in the model at all."). Sênior no encanamento. Core na mão do júnior. O diferencial competitivo montado por quem tem menos condição de modelá-lo, enquanto o talento graduado lustra o que qualquer um compraria pronto.

E aqui cabe a única vez que esta série faz as pazes com a palavra da moda. O genérico é commodity. Autenticação, fila, gateway, o encanamento inteiro: compre, terceirize, não reinvente. Evans fecha: "O maior valor de software sob medida vem do controle total do CORE DOMAIN" (no original, "The greatest value of custom software comes from the total control of the CORE DOMAIN."). O core nunca foi commodity e nunca vai ser, porque é exatamente o que ninguém pode comprar no lugar da sua empresa. Quem joga o core na esteira junto com o resto terceiriza o próprio diferencial e chama isso de eficiência.

a linguagem é a invenção

Vaughn Vernon, no livro vermelho, o Implementing Domain-Driven Design, não tem dúvida sobre a contribuição central do Evans: "Se há uma única 'invenção' que Evans entrega à comunidade de desenvolvimento de software, é a Linguagem Ubíqua" (no original, "If there is a single 'invention' Evans delivers to the software development community, it is the Ubiquitous Language."). Não são os padrões táticos. É a língua comum entre negócio e código.

E é aqui que mora a armadilha mais popular, que Vernon batiza de DDD-Lite: pegar a metade fácil, os padrões táticos que o dev implementa (Entities, Repositories, Aggregates), e pular a metade estratégica, a de negócio: linguagem ubíqua, bounded context, core domain. O veredito dele é direto: "Dito de forma simples, praticar DDD-Lite leva à construção de modelos de domínio inferiores" (no original, "Simply stated, practicing DDD-Lite leads to the construction of inferior domain models."). Você fica com a aparência de DDD, os Repositories no lugar, e um modelo anêmico por dentro, um CRUD com sotaque de arquitetura. Já argumentei isso em Antes de Falar em IA, Arruma Esse CRUD: sem domínio de verdade, você tem tabela com verbo, não modelo. Vale pra produto também: backlog não é design, spec não é modelo.

Modelo inferior custa dinheiro em produção. Vernon conta um caso do próprio livro que cura quem acha isso abstrato. Um Aggregate grande foi desenhado sobre invariantes que os devs imaginaram, não sobre as regras reais do negócio. Resultado: quebrou em produção com dois usuários simultâneos. Dois. E a correção não foi mais banco, não foi tuning, não foi hardware. Foi entender a regra de verdade e remodelar: "resolvemos o problema de falha transacional modelando-o pra fora" (no original, "So we've solved the transaction failure issue by modeling it away."). O gargalo não estava na infra. Estava no entendimento do domínio, que alguém inventou em vez de descobrir. Máquina maior nenhuma consertaria aquilo.

e a IA tornou isso urgente

Evans escreveu isso em 2003. Vernon, em 2013. Nenhum dos dois viu um LLM na vida, e eu não vou botar palavra de IA na boca deles. Mas tem uma frase do Evans, no epílogo, que envelheceu como profecia. Sobre as tentativas de automatizar design da época, ele escreveu: "criar bom software é primariamente uma atividade de aprendizado e pensamento... Esforços para automatizar o que deve ser produto do pensamento são ingênuos e contraproducentes" (no original, "creating good software is primarily a learning and thinking activity... Efforts to automate what must be the product of thought are naïve and counterproductive."). Ele falava das ferramentas de 2003, não de IA generativa. A transposição pra LLM é minha, e o princípio só ganhou força.

Porque a IA generativa tem duas pontas, e o modelo do domínio manda nas duas.

A entrada primeiro. Um LLM gera a partir do contexto que você dá. Linguagem fraturada, "ordem" com três sentidos em três times, modelo raso: o prompt sai ambíguo, e a máquina herda a sua ambiguidade com uma confiança que você não tem. Ela não corrige o seu modelo. Amplifica o que recebeu. Agora inverte o cenário: linguagem ubíqua clara, compartilhada entre negócio e engenharia, é na prática a melhor engenharia de prompt que existe pro seu domínio. Já defendi isso em Prompt Engineering Que Funciona em Produção, Não Só em Playground: o que faz o prompt funcionar não é a fórmula mágica, é o contexto de domínio por trás dele.

A saída é pior, porque é silenciosa. Sem modelo explícito e sem invariantes escritos, não existe régua pra dizer se o que a IA gerou está certo pro negócio. Sobra "parece certo". E "parece certo" é como nasce o lixo plausível: código que compila, roda, passa no olhar distraído e viola uma regra de negócio que ninguém escreveu. Lembra do oráculo independente do artigo sobre testes? O valor esperado tem que vir de fora do gerador, de quem conhece o domínio. Pois é: o valor esperado é o domínio. Sem ele, você não valida a saída da máquina, só acha ela convincente.

Vernon tem a imagem certa pra isso, escrita uma década antes de qualquer LLM. Conceito de domínio que falta não some quieto. Fica "acenando as mãos e gritando pra você" (no original, "waving its hands and shouting at you") em cada atrito de implementação, cada if estranho, cada exceção que não devia existir. Só que a máquina não escuta esse grito. Não descobre o conceito que falta: contorna o atrito com mais código e entrega tudo funcionando o suficiente pra passar no review. O que faltava continua faltando, agora escondido mais fundo.

o que sobra escasso

DDD, no fim, faz uma coisa só, e ela é de gestão antes de ser de engenharia: devolve a complexidade pro lugar onde ela nasce e se resolve, o domínio. Produto na sala de modelagem não é luxo nem cerimônia. É a diferença entre construir o software certo e construir certo o software errado. Dá pra ter engenharia impecável sobre um modelo que não entende o negócio: um sistema bem construído resolvendo o problema errado. Rápido, testado e inútil.

Na era da IA isso ficou mais escasso, não menos. A digitação virou commodity de verdade; a máquina cospe código mais rápido do que a discussão de prazo acompanha. O que ficou raro é saber o que dizer pra ela e como validar o que ela devolve. E isso não sai de gerador nenhum: sai de gente que entende o negócio sentada na mesma mesa que gente que entende o código.

Em bolsa e em exchange de cripto dá pra ver o preço disso de perto. "Ordem", "posição", "liquidação" não são palavras genéricas ali; cada uma tem significado preciso, com invariante e regra de negócio que quebra dinheiro real quando está errada. Produto que não fala essa língua não prioriza direito o que importa, quanto mais valida o que uma máquina gera sobre o domínio. A linguagem não é enfeite do modelo. É o modelo. E nunca foi coisa de dev.

Insights & Takeaways

• A complexidade que quebra o produto mora no domínio, não no código. Evans abre o DDD com isso. Deixar essa complexidade inteira na mão da engenharia é uma decisão de risco, quase sempre tomada por omissão.
• Produto na sala de modelagem não é luxo nem cerimônia. Se o especialista de domínio não entende o modelo, o modelo está errado; a divisão de linguagem nunca deve ser entre quem entende o negócio e quem escreve o código.
• Quem desenha os times desenha o modelo. Bounded context é decisão de gestão, não de design interno: as fronteiras seguem o organograma (Conway), e o Accelerate adota o conceito por nome como fundamento de entrega.
• O genérico é commodity, compre e terceirize; o core nunca foi e nunca será. Colocar o melhor talento no encanamento e o diferencial na mão do júnior é entregar de graça o que distingue a sua empresa.
• Sem linguagem ubíqua, a IA não tem contexto de entrada nem régua de saída. Modelo claro é o melhor prompt do seu domínio e a única forma de dizer se o que a máquina gerou está certo pro negócio, ou só parece.