O que é Domain-Driven Design (DDD)?

Eric Evans reuniu os padrões e o vocabulário de Domain-Driven Design no livro Domain-Driven Design: Tackling Complexity in the Heart of Software, publicado em 2003. Modelar o domínio já era uma preocupação anterior da engenharia de software; sua contribuição foi articular linguagem, colaboração e desenho estratégico e tático como prática contínua.

Evans publicou depois uma referência dos padrões de DDD. Os conceitos se difundiram para arquiteturas e organizações diferentes, sem obrigar o uso de microsserviços. A modelagem deve evoluir com o aprendizado sobre o domínio e com o software em uso.

DDD parte de uma pergunta concreta: que regras e distinções realmente importam para o negócio que o software atende? Num serviço de reservas, “vaga”, “reserva” e “confirmação” podem ter significados diferentes para vendas, operação e cobrança. Se o código tratar tudo como registros genéricos, essas diferenças aparecem como condições espalhadas e difíceis de alterar. A equipe conversa com especialistas, observa exemplos e constrói um modelo que explicita as regras relevantes.

Linguagem ubíqua. Desenvolvedores e especialistas de domínio usam termos comuns nas conversas, exemplos, testes e código. Não é apenas um glossário colado na parede. Se todos dizem “reserva confirmada”, o software deve representar esse estado e suas transições com o mesmo significado. Quando uma palavra é ambígua, a divergência vira pergunta de modelagem. A linguagem muda conforme a equipe aprende; forçar uma definição prematura pode esconder diferenças reais.

Contexto delimitado. Um grande sistema raramente comporta um único modelo coerente para toda a organização. “Cliente” pode significar pagador em cobrança e usuário atendido em suporte. Um bounded context delimita onde um modelo e sua linguagem valem. Entre contextos, traduções e contratos explícitos evitam que uma interpretação invada a outra. A fronteira é conceitual e organizacional; não corresponde automaticamente a um microsserviço, repositório ou banco de dados.

Mapa de contextos. Quando há vários modelos, o time descreve relações entre eles e as dependências de integração. Quem fornece informação? Quem precisa traduzir termos? Onde uma mudança em uma regra terá efeito? O mapa não é um desenho definitivo da arquitetura, mas uma ferramenta de conversa que pode mudar com a organização. Fronteiras mal compreendidas geram sincronizações frágeis e disputas sobre quem decide a definição de um dado.

Modelagem tática. Dentro de um contexto, padrões como entidades, objetos de valor, agregados e eventos de domínio ajudam a expressar regras. Uma entidade preserva identidade ao longo de mudanças. Um objeto de valor é definido por atributos e significado, não por uma identidade própria. Um agregado estabelece uma fronteira para preservar invariantes ao alterar dados relacionados. Um evento de domínio registra algo relevante que aconteceu. Esses padrões são opções para representar o modelo, não peças obrigatórias de todo sistema.

Um agregado mal desenhado pode ficar grande demais e dificultar mudanças simultâneas; pequeno demais, pode deixar uma regra sem proteção. A escolha depende das invariantes reais: o que precisa ser consistente no mesmo momento? Uma reserva não pode ser confirmada duas vezes? Uma vaga precisa ser bloqueada antes da cobrança? Perguntas desse tipo são mais úteis do que começar por diagramas de classes.

Aprendizado contínuo. Uma sessão de modelagem pode revelar termos e regras, mas o trabalho não termina ali. Ao implementar e testar casos reais, a equipe encontra exceções que pedem revisão do modelo. Refatorar o código para refletir o novo entendimento faz parte da abordagem. Congelar um desenho completo antes de construir contraria o valor de aprender com o software. Práticas da XP, como testes e refatoração, podem ajudar a sustentar essa evolução.

Escolha onde investir. Nem toda parte do produto precisa de modelagem sofisticada. Uma função de autenticação comum ou um relatório simples podem usar soluções conhecidas. O maior esforço de DDD costuma valer nos domínios em que regras específicas diferenciam o serviço ou criam maior complexidade. Aplicar entidades e agregados a um cadastro trivial pode acrescentar camadas sem benefício.

DDD não é sinônimo de microsserviços. Um monólito pode conter contextos claros e modelos bem separados. Uma coleção de microsserviços pode ter linguagem confusa e regras duplicadas. Decidir como implantar é outra conversa, dependente de equipes, capacidade operacional e necessidade de independência. Comece pelas fronteiras de significado; depois escolha como implementá-las.

Event Storming é uma técnica de descoberta que pode reunir especialistas e desenvolvedores para explorar acontecimentos e regras do domínio. Não é etapa obrigatória de DDD. Entrevistas, exemplos de casos, análise de fluxos e conversas sobre incidentes também podem fornecer matéria-prima para o modelo.

DDD ajuda a reduzir dívida técnica quando evita que uma regra importante fique dispersa, mas não imuniza o sistema contra complexidade. Uma linguagem que só existe em slides, sem relação com código e decisões, vira cerimônia. A prova está na facilidade de explicar, testar e alterar comportamentos do domínio quando a realidade muda.

Imagine uma plataforma hipotética de hospedagem com 3 áreas: busca, reservas e cobrança. Todas usam a palavra “reserva”, mas com sentidos distintos. Na busca, uma opção exibida ainda não compromete inventário. Em reservas, uma vaga confirmada precisa estar disponível. Em cobrança, há uma autorização de pagamento que pode ocorrer antes ou depois da confirmação, conforme a regra escolhida. Esses detalhes são inventados para exemplificar fronteiras.

Antes, o sistema usa uma tabela única chamada reserva, com um campo status interpretado por cada área. Uma mudança para permitir pagamento posterior altera condições em 5 serviços e produz relatórios inconsistentes: cobrança chama de confirmada uma opção que reservas ainda considera pendente. O número não descreve caso real.

A equipe conversa com especialistas de cada área e separa os contextos. Define linguagem local: na busca há oferta, em reservas há solicitação e confirmação, em cobrança há autorização e liquidação. Desenha contratos de integração que traduzem os eventos relevantes. Dentro do contexto de reservas, explicita a regra que impede duas confirmações para a mesma vaga.

Depois, uma mudança no prazo de autorização tem um lugar claro para ser discutida e implementada. Ainda haverá integração e casos difíceis, mas a equipe sabe que “confirmado” não deve ser enviado sem contexto. Testes cobrem transições que importam para o negócio, não apenas campos da tabela.

Outro exemplo, fora de um produto de software comercial, seria um serviço público de matrícula. “Vaga” pode significar capacidade planejada numa secretaria e assento efetivamente disponível numa escola. Modelar as duas interpretações sem misturá-las ajuda a explicar por que números que parecem iguais divergem. DDD não resolve a política pública, mas impede que o software esconda uma distinção essencial.

Curso K21 recomendado