Quando uma área diz “pedido”, outra pode estar falando de uma intenção de compra, e uma terceira, de uma obrigação que já precisa ser faturada. Se o software tratar essas três coisas como o mesmo objeto, a confusão aparece em regras contraditórias, exceções espalhadas e mudanças que quebram fluxos que pareciam não ter relação.
É nesse tipo de complexidade que Domain-Driven Design (DDD) ajuda. A proposta é entender o domínio com as pessoas que conhecem o negócio e fazer esse entendimento aparecer no modelo e no código. DDD não é um framework, uma linguagem de programação ou uma receita de pastas.
DDD começa pelas perguntas certas
Eric Evans apresentou Domain-Driven Design como uma abordagem para desenvolver software em torno de um modelo rico do domínio. O modelo não deve ficar preso a diagramas produzidos no início do projeto: ele precisa ser exercitado no código, confrontado com exemplos reais e refinado conforme a equipe aprende.
Isso muda o ponto de partida. Em vez de começar escolhendo microsserviços, entidades de banco ou nomes de tabelas, a equipe investiga como o trabalho acontece: quais decisões são tomadas, quais regras não podem ser violadas, onde aparecem exceções e que palavras as pessoas usam para explicar cada situação.
Martin Fowler resume a ideia central em sua introdução a Domain-Driven Design: construir software em torno de um modelo que represente o domínio e de uma linguagem compartilhada por quem desenvolve e por quem conhece o negócio.
Uma linguagem comum precisa sobreviver ao código
DDD chama de linguagem ubíqua a linguagem que especialistas do domínio e desenvolvedores constroem juntos e usam nas conversas, nas regras, nos testes e no software. “Comum” aqui não significa escolher uma palavra bonita para um glossário. Significa que, quando alguém usa um termo importante, o grupo consegue explicar o que ele quer dizer naquele contexto.
Imagine uma operação que usa “cliente” para falar da pessoa que compra, da empresa que assina o contrato e do contato que abre um chamado. Talvez essas três ideias compartilhem dados, mas não têm necessariamente o mesmo papel ou as mesmas regras. Se o sistema as amontoar em um único objeto chamado Cliente, as ambiguidades podem virar dependências difíceis de desfazer.
Uma boa técnica é pedir exemplos concretos: “O que precisa acontecer para um orçamento virar pedido?”, “Em que situação um pedido pode ser cancelado?” e “Quem pode alterar a condição de pagamento depois da aprovação?”. Cada resposta põe o vocabulário à prova. Martin Fowler, ao escrever sobre linguagem ubíqua, destaca a troca contínua entre modelo, conversa e conhecimento dos especialistas.
Quando a equipe encontra uma palavra ambígua, vale registrar os sentidos separados. Não é uma falha de comunicação que precisa ser escondida; é uma pista de que podem existir modelos diferentes dentro do mesmo negócio.
Contextos delimitados dão lugar a modelos diferentes
Um bounded context, ou contexto delimitado, define onde um modelo e sua linguagem são consistentes. Dentro daquela fronteira, uma palavra deve ter significado suficientemente claro para orientar as regras. Fora dela, outro contexto pode usar o mesmo termo com outra intenção.
Uma área de vendas pode chamar de “pedido” uma negociação aprovada que ainda aguarda pagamento. No financeiro, “pedido” pode significar uma obrigação faturável; na logística, talvez seja uma separação de itens que só começa depois da confirmação do pagamento. O sistema não precisa forçar essas áreas a compartilhar a mesma estrutura interna. Precisa explicitar como cada contexto conversa com os outros.
O artigo de Martin Fowler sobre Bounded Context explica por que grandes domínios costumam exigir modelos consistentes em fronteiras menores. A análise de domínio da Microsoft também recomenda mapear capacidades, dependências e subdomínios antes de decidir como implementar serviços.
Essas fronteiras não obrigam a equipe a adotar microsserviços. Um contexto delimitado pode viver como um módulo dentro de um monólito. O benefício vem primeiro da clareza do modelo e de suas relações; a distribuição física é uma decisão posterior, tomada diante de necessidades concretas de implantação, escala, autonomia ou operação.
Nem todo domínio merece o mesmo investimento
Na análise estratégica, é útil separar o que diferencia o negócio daquilo que só o mantém funcionando e do que já é um problema genérico resolvido por ferramentas existentes. A Microsoft descreve essas categorias como subdomínios centrais, de suporte e genéricos.
Uma regra que determina como a empresa precifica ou aprova uma operação pode merecer modelagem cuidadosa porque afeta a proposta do negócio. Autenticação ou envio de e-mail podem ser importantes, mas talvez não sejam o lugar onde a empresa se diferencia. Essa distinção ajuda a concentrar o esforço: não precisamos inventar um domínio complexo para cada parte do sistema.
O mapa de contextos também registra relações: quem fornece dados, quem os consome, onde um sistema externo impõe seu vocabulário e onde uma camada de tradução protege o modelo interno. Isso reduz o risco de deixar o formato de uma API externa se espalhar por toda a aplicação.
Os padrões táticos protegem regras dentro do modelo
Depois de entender os contextos, os padrões táticos ajudam a representar comportamentos e invariantes:
- Entidade: algo cuja identidade importa ao longo do tempo, mesmo que seus dados mudem.
- Objeto de valor: um conceito definido por seus valores, como um intervalo de datas ou uma quantia com moeda, sem identidade própria relevante.
- Agregado: um limite de consistência dentro do qual regras relacionadas precisam ser preservadas; sua raiz controla as mudanças relevantes nesse conjunto.
- Serviço de domínio: uma operação do domínio que não pertence naturalmente a uma entidade específica.
- Evento de domínio: um fato significativo que já ocorreu, como uma reserva confirmada, e que outros fluxos podem tratar.
Considere um pedido que não pode ser confirmado sem itens válidos e uma condição de pagamento aceita. Se essa regra for copiada entre telas, rotas e integrações, as versões acabam divergindo. Um modelo de domínio pode oferecer uma operação explícita, como confirmar o pedido, e proteger a regra no lugar em que ela faz sentido.
A referência da Microsoft sobre modelos de domínio mostra como entidades e raízes de agregados preservam comportamento e invariantes. Ela também observa que um serviço CRUD simples pode não justificar padrões mais sofisticados de DDD.
Agregado não é uma pasta para juntar tabelas
Um erro comum é transformar cada relação do banco em um agregado grande. Mas o agregado representa um limite de consistência do domínio, não um agrupamento conveniente de entidades. Para encontrá-lo, comece pelas operações: quais dados precisam mudar juntos para uma regra continuar verdadeira? Quais invariantes a aplicação deve preservar numa única transação?
Uma fronteira muito grande amplia o acoplamento e pode tornar alterações concorrentes difíceis. Uma fronteira pequena demais pode permitir estados inválidos. O desenho deve responder aos comportamentos que o negócio exige, e não reproduzir a estrutura do banco de dados dentro do domínio.
O mesmo cuidado vale para eventos. Chamar toda alteração técnica de “evento de domínio” dilui o significado. Reserve esse nome para fatos reconhecidos pelo domínio e que possam orientar uma reação relevante. Uma mensagem criada porque uma tabela foi atualizada não vira um evento de negócio só por ter sido publicada numa fila.
DDD não significa microsserviços
DDD e microsserviços aparecem juntos com frequência, mas não são sinônimos. A análise estratégica pode ajudar a localizar fronteiras candidatas; isso não significa que cada contexto deva virar um serviço independente. Cada serviço distribuído traz custos de rede, monitoramento, implantação, segurança, dados e suporte operacional.
Um monólito modular pode manter limites de domínio explícitos sem exigir toda essa infraestrutura. Para muitos produtos, é uma forma mais simples de preservar coesão e deixar espaço para separar módulos se uma necessidade real aparecer. O ponto é separar responsabilidades com intenção, não multiplicar processos por princípio.
A documentação da Microsoft alerta que não há um processo mecânico que produza as fronteiras corretas e que a avaliação muda conforme o sistema evolui. As fronteiras devem acompanhar as capacidades do negócio, as dependências e os requisitos não funcionais, em vez de nascerem de um diagrama de moda.
Como começar sem transformar DDD em cerimônia
- Escolha um fluxo com regras reais. Não tente modelar a empresa inteira. Comece por uma jornada com exceções, decisões ou mudanças frequentes.
- Converse com quem executa o trabalho. Capture exemplos, variações, termos ambíguos e situações que dão errado.
- Desenhe eventos e decisões. Uma sessão de event storming ou um mapa simples pode revelar dependências sem exigir um modelo formal de início.
- Defina a linguagem do contexto. Registre conceitos, regras e exemplos; use nomes semelhantes no código quando forem realmente o mesmo conceito.
- Modele uma operação de ponta a ponta. Teste o modelo com exemplos importantes e confirme que ele expressa as regras sem escondê-las em condicionais espalhadas.
- Adie a distribuição física. Primeiro dê forma aos limites e às relações; depois avalie se módulos precisam se tornar serviços separados.
- Revise o modelo quando os fatos mudarem. O domínio evolui, então termos, regras e fronteiras também podem precisar de ajustes.
Se uma parte do sistema é simples, mantenha-a simples. Se outra concentra regras que mudam e afetam decisões importantes, invista mais tempo em compreendê-la. DDD funciona melhor quando a complexidade da solução acompanha a complexidade do problema.
Uma referência para decisões, não uma coleção de cerimônias
O valor de DDD aparece quando o modelo ajuda pessoas diferentes a discutir a mesma regra e quando o código torna essas regras mais fáceis de localizar, testar e mudar. A equipe não precisa adotar todos os padrões de uma vez. Precisa criar um ciclo em que conversa, modelo e implementação possam corrigir uns aos outros.
Para se aprofundar, vale começar por Domain-Driven Design: Tackling Complexity in the Heart of Software, de Eric Evans, acompanhar os artigos de Martin Fowler sobre DDD e contextos delimitados, e consultar os guias da Microsoft sobre análise de domínio e modelos de domínio.