Domain-Driven Design tem fama de ser "coisa de projeto grande", algo que só se justifica em sistemas com dezenas de desenvolvedores. Discordo. Uso DDD até em projetos pequenos, e a razão é simples: o problema que o DDD resolve — regra de negócio se espalhando pelo código sem organização — aparece cedo, não só em escala.
O que eu levo, mesmo em pouco código
Não aplico o pacote completo de DDD em um projeto pequeno. O que eu levo é a disciplina de nomear as coisas como o negócio as nomeia, e separar regra de domínio de detalhe de infraestrutura (banco, e-mail, fila) desde a primeira linha. Isso custa pouco no início e evita um retrabalho caro depois, quando o projeto pequeno vira médio — e quase todo projeto que sobrevive vira.
Na prática, isso significa criar uma pasta de domínio separada dos Controllers desde o dia um, mesmo que ela comece com uma única classe. Significa também escrever um método chamado calcularElegibilidade() em vez de check(), porque o nome carrega significado que o código sozinho não carrega. São decisões pequenas, quase invisíveis no primeiro commit, que fazem toda a diferença no centésimo.
O ponto de equilíbrio
A armadilha oposta também existe: forçar camadas e abstrações em um script que vai rodar uma vez e morrer. DDD é sobre reduzir custo de mudança ao longo do tempo — se não há "ao longo do tempo", a técnica não se paga. A pergunta que faço antes de decidir é sempre a mesma: esse código vai crescer, vai ser mantido por mais de um mês, vai receber novas regras? Se sim, vale organizar desde o início.
Onde isso me levou
Foi assim que o Simulado Solidário nasceu já com domínio separado de infraestrutura, e é por isso que hoje consigo adicionar uma funcionalidade nova — como um novo tipo de relatório administrativo — sem precisar reler o sistema inteiro para lembrar onde cada coisa mora. Se você quer entender como essa separação funciona na prática, com Portas e Adaptadores, escrevi sobre isso em Arquitetura Hexagonal na prática.
