Introdução
Por que saber DDD não significa nada se você não entende o problema.
Todo líder quer uma equipe que resolva as coisas. Ou, ao menos, é isso que ele diz. Na prática, muitos líderes não querem que as coisas sejam resolvidas. Querem manter o controle. Não querem ser desafiados. E, principalmente, não querem lidar com alguém mais competente do que eles em alguma área-chave.
E assim, o problema principal — resolver o processo da empresa com uma ferramenta eficaz — se perde no meio da vaidade, do medo e da mediocridade.
Perfeito. A analogia da forja é forte, mas como você pediu uma nova analogia, aqui vai uma alternativa com o mesmo peso simbólico — porém mais próximo da construção civil, que também lida com especialização, abstração e realidade prática.
A analogia do canteiro de obras
Imagine que uma empresa decide construir um prédio. Algo funcional, com salas administrativas, banheiros, área técnica e espaços de atendimento. Mas, ao montar a equipe, ela contrata:
- Um especialista em jardins japoneses;
- Um artista da marcenaria artesanal;
- Um decorador premiado com foco em lofts minimalistas.
Todos são excelentes no que fazem. Mas nenhum deles sabe levantar fundações, lidar com encanamento ou entender normas técnicas de estrutura.
Pior: cada um tenta encaixar sua visão estética no projeto — mesmo sem saber onde fica o quadro de luz. Resultado? O prédio pode até ficar bonito nas fotos. Mas ninguém consegue trabalhar lá dentro.
É o que vemos hoje na TI:
- Gente que sabe usar ferramentas sofisticadas — mas não sabe onde aplicar.
- Equipes que entregam “componentes reutilizáveis” — mas não sabem por que ninguém usa.
- Aplicações cheias de camadas, testes e interfaces — que resolvem o problema errado.
E o que falta?
Alguém que leia a planta. Que entenda a função do prédio. Que fale com o engenheiro civil, o eletricista, o bombeiro hidráulico e o cliente — e consiga transformar isso em algo funcional e seguro.
Esse papel não tem glamour.
Não está nos palcos de conferências.
Mas sem ele, nada para de pé.
A palavra bonita que ninguém entende
Hoje em dia, se você questiona a bagunça, a resposta vem pronta:
“Mas estamos usando DDD.”
Domain-Driven Design virou uma áurea de legitimidade. Mas poucos que falam nela realmente a praticam.
DDD de verdade é:
- Entender profundamente o domínio do problema.
- Refletir esse entendimento no modelo de negócio.
- Transformar esse modelo em software coeso e legível.
DDD não é criar camadas com nomes bonitos. Não é discutir se o repositório vai embaixo do use-case ou se a entity deve ser exposta.
E a verdade é incômoda:
Antes de DDD existir como nome, a gente já fazia isso.
Já modelávamos com base no processo. Já criávamos ferramentas alinhadas com o fluxo real do negócio.
Depois vieram os livros, os eventos, os cursos. Deram um nome bonito para aquilo que já era prática em ambientes maduros. E venderam como se fosse uma nova religião.
Em resumo
- De nada adianta uma equipe cheia de títulos se ninguém sabe construir a ferramenta que resolve o problema.
- DDD não é uma técnica, é uma consequência de saber o que se está fazendo.
- Quem não entende o domínio, mas aplica camadas de software, não está fazendo DDD. Está disfarçando incompetência com terminologia.
Se você sabe onde está o problema, entende a rotina, conhece as exceções, e é capaz de transformar isso em software vivo, parabéns:
Você faz DDD. Mesmo que nunca tenha lido o livro.
E o mundo está cheio de gente que leu o livro — mas não entende o que está fazendo.
