Sabe aquele sistema que começa com a frase clássica: “relaxa, é só um CRUD com umas regrinhas simples”?
Mudanças no cálculo de valores passam a quebrar três telas diferentes no Angular, porque a mesma regra de negócio foi implementada em cinco lugares distintos. A equipe começa a ficar com receio de fazer deploy em produção, e ninguém consegue explicar como o sistema funciona em menos de meia hora — ainda precisando de dois quadros brancos lotados para dar conta da explicação.
Na minha experiência com sistemas de gestão de direitos autorais, financeiros e migração de legados, essa é a trilha mais comum do caos quando não existe uma preocupação real com o domínio. E é exatamente aqui que a conversa sobre DDD entra. Não como teoria bonita, mas como sobrevivência.
O problema real que DDD tenta resolver
DDD não se trata de usar termos sofisticados como "Aggregate" e "Bounded Context". Trata-se de controlar a complexidade do negócio antes que ela arruíne seu código. Em certos domínios, negligenciar isso tem um preço alto. A dor por trás do “sistema que virou Frankenstein”
Pensa nesse cenário clássico, que talvez você já tenha visto: um sistema financeiro começa simples, com cadastro de clientes, contratos e lançamentos. No começo, tudo é colocado dentro de serviços de aplicação e controllers; conceitualmente é “um projeto só”, todo mundo mexe em tudo, não existem limites claros entre módulos ou responsabilidades.
Com o tempo, porém, o contexto vai ficando mais complexo: surgem regras fiscais, conciliações bancárias, integrações com terceiros e exceções específicas por tipo de operação. A partir daí começam a aparecer problemas bem conhecidos: campos usados com significados diferentes dependendo do contexto, stored procedures recheadas de regra de negócio escondida, classes enormes que fazem “de tudo um pouco” e bugs em relatórios que afetam diretamente o cálculo de dinheiro de verdade.
DDD nasce justamente para atacar essa dor: como representar o negócio de forma clara e manter a sanidade ao longo do tempo.
DDD não é sobre microserviços ou sobre usar um conjunto fixo de padrões. É sobre deixar o modelo de negócio explícito e bem protegido dentro do seu código.
Quando usar DDD (e quando NÃO usar)
DDD vale o esforço quando o domínio é complexo e muda bastante. Em sistemas simples, DDD completo pode ser exagero. O contexto brasileiro, em especial em áreas reguladas, puxa muito para DDD.
Vamos organizar em três grupos:
- Casos em que DDD é altamente recomendável.
- Casos em que DDD é opcional.
- Casos em que DDD é exagero.
Quando DDD é altamente recomendável
Na minha experiência, DDD deixa de ser opcional e se torna quase obrigatório em certos tipos de domínio. É o caso de gestão de direitos autorais, onde você precisa calcular royalties por tipo de uso, contrato, período e país, lidando com múltiplos atores com interesses diferentes (autores, editoras, entidades de classe, plataformas digitais). Também é o caso de sistemas financeiros, cheios de regras de liquidação, conciliação, tarifas e impostos, em que qualquer erro pode ter alto impacto em dinheiro, compliance e auditoria.
Outro cenário em que DDD costuma fazer muita diferença é na migração de sistemas legados complexos: sistemas com décadas de existência, cheios de regras escondidas em jobs e stored procedures, em que um mesmo registro pode ter significados diferentes dependendo da época. Nessas situações, você precisa de um modelo de domínio bem pensado para conseguir entender, isolar e evoluir a lógica de negócio sem afundar em caos e retrabalho infinito.
Todos esses quadros têm algo em comum: lidam com regras de negócio complexas e cheias de exceções, que mudam o tempo todo por causa de novas legislações, exigências ou tipos de contrato, e em que qualquer erro pode gerar impacto real em dinheiro, contratos ou conformidade.
Nesses casos, minha recomendação é clara: vale investir em DDD. Não só em termos, mas em modelagem de domínio séria.
Quando DDD é opcional
Existem também os casos de meio termo, em que você não precisa montar uma arquitetura pesada de DDD, mas pode se beneficiar bastante de alguns conceitos. São, por exemplo, portais administrativos com poucas regras complexas, APIs de cadastro com lógica simples e relativamente estável, ou aplicações internas de apoio, sem impacto financeiro ou legal crítico.
Nesses cenários, minha recomendação é adotar algumas ideias de DDD — como entidades de domínio com comportamento (e não apenas DTOs glorificados), Value Objects para dar significado a tipos primitivos e nomes que reflitam a linguagem do negócio — mas mantendo a arquitetura enxuta: separar bem domínio, aplicação e infraestrutura, sem exagerar na quantidade de projetos, camadas e padrões.
Você se inspira em DDD, mas não abraça o “pacotão enterprise” completo.
Quando DDD é exagero
Também existem situações em que tentar aplicar DDD completo mais atrapalha do que ajuda. É o caso de MVPs muito simples que talvez nem cheguem à produção, provas de conceito feitas só para testar uma tecnologia ou ferramentas internas que são basicamente CRUD em cima de três ou quatro tabelas.
Nesses cenários, minha recomendação é focar em boas práticas de design — separar responsabilidades básicas, evitar colocar regra de negócio direto no controller — mas sem gastar energia com bounded contexts separados sem necessidade, arquiteturas super elaboradas com dezenas de projetos ou um “dicionário de termos DDD” para algo que, na prática, é só cadastro.
Se você consegue explicar o domínio inteiro em 5 minutos sem desenhar nada e sem ficar “mas tem uma exceção aqui…” provavelmente DDD completo é exagero.
DDD como ponte entre o caos do mundo real e um modelo de domínio mais controlado.
Como DDD se encaixa em .NET Core, Angular e Azure
DDD não é uma arquitetura em si, mas se encaixa muito bem com o .NET moderno: um monolito bem estruturado já é um excelente ponto de partida, enquanto Angular e Azure entram como “meios” de entrega e infraestrutura, não como o lugar onde a regra de negócio deve morar.
Monolito bem estruturado primeiro
Muita gente associa DDD com microserviços, mas a minha sugestão é o oposto:
Comece com um monolito modular em .NET 8, separe bem as responsabilidades:
- Domínio
- Aplicação
- Infraestrutura
- API
Depois, se fizer sentido, você pode evoluir partes específicas para serviços separados.
Um desenho mental simples
O Angular fala com a API, que orquestra casos de uso na camada de aplicação. A lógica de negócio mora no domínio. Infraestrutura faz o trabalho “sujo” (banco, filas, integrações).
Código de domínio em .NET 8: foco no negócio
Vamos pegar um exemplo simples inspirado em gestão de direitos autorais: cálculo de repasse de royalties.
public sealed class Money
{
public decimal Amount { get; }
public string Currency { get; } public Money(decimal amount, string currency = "BRL")
{
if (amount < 0)
throw new ArgumentException("Valor não pode ser negativo.", nameof(amount)); if (string.IsNullOrWhiteSpace(currency))
throw new ArgumentException("Moeda é obrigatória.", nameof(currency)); Amount = amount;
Currency = currency.ToUpperInvariant();
} // Cria um novo Money multiplicado por um fator
public Money Multiply(decimal factor)
=> new Money(Amount * factor, Currency); public override string ToString()
=> $"{Amount:F2} {Currency}";
}// Entidade de domínio para um contrato de direitos autorais
public sealed class ContratoDireitosAutorais
{
public Guid Id { get; }
public Guid AutorId { get; }
public decimal PercentualRepasse { get; private set; } // 0.15 = 15% public ContratoDireitosAutorais(Guid autorId, decimal percentualRepasse)
{
if (percentualRepasse <= 0 || percentualRepasse > 1)
throw new ArgumentException("Percentual deve estar entre 0 e 1.", nameof(percentualRepasse)); Id = Guid.NewGuid();
AutorId = autorId;
PercentualRepasse = percentualRepasse;
} // Regra de negócio: cálculo do repasse com base na receita bruta
public Money CalcularRepasse(Money receitaBruta)
{
return receitaBruta.Multiply(PercentualRepasse);
}
}
Repara em alguns pontos importantes:
- O domínio não sabe nada de banco, API, Angular ou Azure.
- A regra de negócio “repasse = receita * percentual” está encapsulada no domínio.
- Os nomes refletem o negócio, não a tecnologia.
Essa é a mentalidade que DDD ajuda a construir.
Checklist prático: meu projeto precisa de DDD?
Agora vamos para a parte mais prática: um checklist simples para você decidir se vale ou não investir em DDD de forma mais pesada.
Responda cada item com “Sim” ou “Não”:
- O domínio tem muitas regras e exceções? Exemplo: vários tipos de contrato, regras fiscais, tipos de operação, etc.
- As regras mudam com frequência? Novas legislações, novas formas de cobrança, novos modelos de contrato.
- Erros podem gerar impacto financeiro ou legal relevante? Multas, pagamentos errados, quebra de contrato.
- Há muitos atores diferentes usando o sistema de formas distintas? Ex.: financeiro, comercial, jurídico, operações.
- Você precisa frequentemente explicar o sistema desenhando o fluxo em um quadro?
- O time de negócio usa uma linguagem e o código usa outra? Ex.: o negócio fala “obra”, o código fala “ItemCadastro”.
- Um ajuste aparentemente simples costuma quebrar coisas em lugares inesperados?
- Vocês já cogitaram microserviços só para tentar reduzir o caos?
Agora, veja o resultado:
- Se você marcou 5 ou mais “Sim” Minha recomendação: vale investir em DDD de forma estruturada.
- Se marcou 3 ou 4 “Sim” Eu sugiro começar com DDD “light”: boa modelagem de domínio, value objects, separação de camadas, sem exagero de complexidade.
- Se marcou 2 ou menos “Sim” Provavelmente DDD completo não é prioridade. Foque em boas práticas de design e mantenha o código simples.
Quanto mais o sistema lida com dinheiro, contratos e leis, maior a chance de DDD te economizar muita dor de cabeça no médio e longo prazo.
Armadilhas comuns ao tentar aplicar DDD
Para fechar o artigo, vale listar alguns erros que eu vejo com frequência quando o assunto é DDD.
DDD só na pasta, não no código
O time cria:
- Pasta
Domain. - Pasta
Application. - Pasta
Infrastructure.
Mas:
- Toda regra de negócio fica em controllers ou services genéricos.
- Entidades são apenas sacos de propriedades sem comportamento.
- A linguagem do negócio não aparece em lugar nenhum.
Isso não é DDD. É só uma organização de pastas com nome bonito.
DDD como desculpa para overengineering
Forçar:
- 12 projetos .csproj.
- 5 bounded contexts inventados logo no início.
- Três níveis de abstração para cada coisa.
Para um sistema que não precisa disso tudo. Resultado: ninguém entende a arquitetura, e o ganho real é mínimo.
Confundir DDD com microserviços
Essa é clássica:
“Se é DDD, então cada bounded context tem que ser um microserviço.”
Minha recomendação:
- Use bounded contexts para organizar o domínio dentro de um monolito.
- Só quebre em microserviços quando:
- Os limites estiverem claros.
- Houver necessidade real (escalabilidade, autonomia de times, etc.).
Próximos passos: trazendo DDD para o seu dia a dia
Se eu pudesse resumir este primeiro artigo em uma frase, seria:
DDD não é sobre seguir um livro à risca, é sobre levar o domínio a sério.
Meus próximos passos sugeridos para você:
- Olhe para o sistema em que você trabalha hoje e faça o checklist.
- Identifique uma área do domínio onde as regras estão mais confusas.
- Escolha uma pequena parte e tente:
- Nomear melhor as entidades.
- Extrair value objects.
- Trazer a regra de negócio para dentro do domínio.
No próximo artigo dessa série, a ideia é ir um pouco mais fundo em:
- Linguagem ubíqua.
- Bounded contexts de verdade.
- Como começar a modelar o domínio em .NET sem travar o time.
