DDD não é frescura acadêmica

DDD não é frescura acadêmica

DDD não é frescura acadêmica

Japa Tela Preta #2

Todo sistema começa bonito.

Você abre o projeto e dá até gosto. Pastas organizadas, controllers limpos, services bem definidos. Parece que agora vai. Dessa vez vai ficar redondo.

Só que o tempo passa.

Entram novas features, prazos apertam, aparecem exceções, ajustes rápidos viram solução definitiva… e quando você percebe, já tem regra de negócio no controller, validação duplicada no front, lógica espalhada em três lugares diferentes e ninguém mais tem coragem de mexer sem rezar antes.

Nasce ali o clássico sistema macarrão.

E o mais curioso é que isso não acontece por falta de capacidade técnica. Acontece porque, no dia a dia, ninguém está pensando em arquitetura — está todo mundo tentando entregar.

Foi justamente pra evitar esse tipo de cenário que surgiram conceitos como Domain-Driven Design, Arquitetura Hexagonal, Clean Architecture e até os princípios do SOLID.

Os nomes são pomposos, quase acadêmicos, mas a ideia por trás é bem pé no chão: parar de misturar regra de negócio com detalhe técnico.

Porque detalhe técnico muda o tempo todo.

Framework muda. Banco muda. Ferramenta muda. Biblioteca muda.

Mas a lógica do negócio — aquilo que realmente faz o sistema existir — não deveria ficar refém disso.

É por isso que essas abordagens colocam o domínio no centro. Não como conceito bonito, mas como estratégia prática. Tudo que é externo — banco, API, fila, interface — vira só um adaptador em volta da regra de negócio.

Quando você acerta essa separação, acontece uma coisa interessante: o sistema começa a ficar previsível. Evoluir deixa de ser um jogo de adivinhação. O risco de quebrar algo diminui bastante. E, talvez o mais importante, o código começa a fazer sentido pra quem chega depois.

Isso não vem de livro.

Vem de cicatriz.

De quem já pegou sistema grande, sem padrão, com lógica espalhada, e teve que manter aquilo funcionando enquanto o negócio continuava rodando.

No fim, DDD não é frescura.

É só uma forma de não transformar seu próprio produto no seu maior problema.

Picture of Willian Sanada
Willian Sanada