O Domain-Driven Design (DDD) é uma abordagem para criar sistemas de software que realmente refletem o que o negócio precisa.
Mais do que técnicas de programação, o DDD é sobre comunicação, colaboração e entendimento profundo do problema que estamos tentando resolver.
Por que usar DDD?
Imagine um sistema financeiro, um e-commerce ou uma plataforma de saúde.
Há regras, exceções, integrações, pessoas com papéis diferentes… ou seja, problemas complexos. O DDD brilha justamente nesses contextos, onde o software precisa ser flexível, claro e evolutivo.
Ao aplicar DDD, criamos modelos que imitam o mundo real do negócio, com times técnicos e especialistas trabalhando juntos falando a mesma língua.
Conceitos Fundamentais
Domínio
O universo do problema que queremos resolver, saúde, finanças, educação, logística…
Linguagem Ubíqua
Um vocabulário compartilhado por todos, presente no código, nas conversas e na documentação.
Exemplo: “consulta médica”, “elegibilidade”, “coparticipação”.
Bounded Context (Contexto Delimitado)
O espaço onde essa linguagem faz sentido. Dentro dele, todos entendem os termos da mesma forma.
Isso evita confusão entre áreas diferentes do sistema.
Design Estratégico: visão ampla do sistema
O Design Estratégico ajuda a decidir como dividir o sistema de maneira alinhada ao negócio.
Subdomínios
Cada parte do domínio vira um contexto separado no código. Há três tipos principais:
🥇 Core Domain: onde está o diferencial competitivo.
🥈 Supporting Subdomain: importante, mas não é o coração do negócio.
🥉 Generic Subdomain: comum a várias empresas (ex: RH, faturamento). Nesses casos, vale usar algo pronto.
Context Mapping
Define como diferentes contextos se comunicam. Alguns padrões comuns:
- Parceria: colaboração intensa.
- Customer-Supplier: um fornece, o outro consome.
- Anti-Corruption Layer: cria uma “tradução” para proteger seu modelo de sistemas externos.
Design Tático: o detalhe que dá forma
Aqui entram os blocos de construção que tornam o domínio modular e coeso — mesmo em monólitos.
- Entidades e Aggregates: objetos com identidade e regras de consistência.
- Value Objects: valores imutáveis (como endereço, status, moeda).
- Commands e Events: ações que disparam mudanças e notificam eventos ocorridos.
- Domain Services: regras de negócio que não pertencem a uma única entidade (ex: cálculo de coparticipação).
- Módulos: organizam o código dentro de cada contexto (ex: renovação, cancelamento…).
Arquiteturas que potencializam o DDD
Ports and Adapters (Arquitetura Hexagonal)
Separa o núcleo do sistema das interfaces externas (APIs, bancos de dados, mensageria).
O domínio permanece limpo e independente.
Event Sourcing
Armazena cada evento ocorrido, não apenas o estado final.
Excelente para rastreabilidade e histórico (ex: agenda médica).
CQRS
Separa leitura (queries) e escrita (commands), aumentando clareza e performance.
Microserviços, Orquestração e Coreografia
Cada bounded context pode se tornar um microserviço.
- Coreografia: serviços reagem a eventos de forma autônoma.
Exemplo: evento “ConsultaSolicitada” aciona elegibilidade, cobrança e risco. - Orquestração: um serviço central comanda o fluxo — como um maestro guiando a sinfonia.
Conclusão
O DDD é sobre pessoas, negócio e software em harmonia!
Mais do que um conjunto de padrões, o DDD é uma filosofia de design centrada no negócio. Ele funciona melhor quando:
- O problema é complexo.
- A comunicação entre times é clara.
- Existe colaboração constante entre tecnologia e negócio.
- Queremos evitar sistemas frágeis e difíceis de evoluir.
Ao aplicar DDD, criamos softwares que fazem sentido, evoluem com o tempo e impulsionam o crescimento do negócio.
DDD é sobre traduzir o que as pessoas entendem em código que o sistema também entende.