Por que DDD não é sobre pastas — é sobre linguagem

Todo time que decide "adotar DDD" começa do mesmo jeito: cria uma pasta Domain, outra Application, outra Infrastructure, distribui as classes entre elas e declara vitória. Seis meses depois, o código continua acoplado, as regras de negócio continuam espalhadas em serviços genéricos, e ninguém no time consegue explicar o domínio sem abrir o Visual Studio. A pasta certa nunca foi o problema. A ausência de uma linguagem ubíqua, sim.

Linguagem ubíqua é o vocabulário que o time de negócio usa para descrever o domínio, aplicado literalmente no código — nos nomes de classes, métodos e eventos. Quando o analista financeiro fala em "estorno", a classe se chama Estorno, não ReversalTransactionDTO. Isso não é purismo acadêmico: é o que permite que uma regra de negócio mude sem que alguém precise traduzir "o que o cliente quis dizer" para "o que o código faz". Sem essa tradução fiel, toda mudança de requisito vira um jogo de telefone sem fio entre quem entende o negócio e quem escreve o código.

O segundo erro é tratar o sistema inteiro como um domínio único. Um ERP não tem um modelo de "Pedido" — tem um modelo de Pedido para o contexto de Vendas, outro para Faturamento, outro para Logística, cada um com atributos e invariantes diferentes. Isso é bounded context: reconhecer que a mesma palavra significa coisas diferentes dependendo de onde você está no negócio, e desenhar limites explícitos entre esses significados em vez de forçar uma entidade universal que tenta satisfazer todo mundo e acaba não servindo bem a ninguém.

Na prática, isso muda como eu estruturo projetos .NET: menos preocupação com se a Entity está na pasta certa, mais preocupação com se o Aggregate protege suas invariantes e se o Bounded Context tem limites claros de comunicação com o resto do sistema — geralmente via eventos ou contratos explícitos, nunca por acesso direto a tabelas de outro contexto. A pasta é consequência dessa modelagem, não o ponto de partida.