Domain-Driven Design é um conjunto de práticas para projetar software a partir da perspectiva do negócio, isto é, do domínio e dos problemas reais que precisam ser resolvidos. O processo ocorre em duas etapas principais:

Design estratégico: feito em colaboração com especialistas do domínio, busca entender profundamente o problema e dividi-lo em partes menores, interconectadas e mais fáceis de solucionar.
Design tático: transforma os resultados do design estratégico em arquitetura e implementação de software.

Hoje, muitos projetos falham por estouro de prazo e orçamento. Diversos estudos apontam temas comum entre as causas:

  • falhas na comunicação
  • requisitos pouco claros
  • objetivos imprecisos
  • coordenação ineficiente

Muitos pensam no Domain-Driven Design como um conjunto de definições técnicas que fazem você “usar” ou não o DDD. Na verdade, DDD é um processo de engenharia que coloca a comunicação eficaz como seu princípio central.

Após ler o livro “Aprenda Domain-Driven Design” de Vlad Khononov, decidi por trazer artigos relacionados ao tema. Neste irei navegar entre as abordagens e características do Design Estratégico.

Press enter or click to view image in full size

Design Estratégico

Como dito acima, o DDD é dividido em duas categorias: estratégica e tática. A parte estratégica responde “o quê estamos construindo” e “por quê?”, enquanto a parte tática responde “como” cada componente será implementado.

Analisando os Domínios de Negócio

O que é um Domínio de Negócio?

Um domínio de negócio é a principal área de atividade de uma empresa, por exemplo:

  • FedEx → entregas
  • Starbucks → café
  • Walmart → varejo

Uma empresa não necessariamente precisa ter apenas um único domínio de negócio, existem empresas que podem atuar em múltiplos domínios, como a Amazon que atua em varejo e computação em nuvem (AWS).

Subdomínio

Subdomínios são partes especializadas do domínio de negócio. Esses subdomínios interagindo entre si descrevem completamente a atuação da empresa.

A Starbucks é conhecida pelo café, mas operar uma rede envolve aluguel de espaços, gestão de estoque, treinamento de funcionários, entre outros. Esses subdomínios devem coexistir de forma equilibrada.

Tipos de Subdomínio

Assim como um sistema de software possui componentes diferentes (banco de dados, back-end, front-end), os subdomínios possuem diferentes papéis estratégicos. Existem três tipos:

  1. Subdomínio principal (core): representa aquilo que diferencia a empresa dos concorrentes. É naturalmente complexo, pois concentra a vantagem competitiva.
  2. Subdomínio genérico: atividades comuns a praticamente todas as empresas. Não geram vantagem competitiva.
  3. Subdomínio de suporte: atividades que dão apoio aos subdomínios principais. Não geram diferenciação, mas são essenciais para o funcionamento da empresa.

Comparando Subdomínios

  1. Vantagem Competitiva
  • Apenas subdomínios principais geram vantagem competitiva.
  • Subdomínios genéricos não geram diferenciação.
  • Subdomínios de suporte apenas auxiliam os principais.
  1. Complexidade
  • Subdomínios principais são complexos por natureza, justamente para dificultar que concorrentes os repliquem.
  • Subdomínios genéricos podem ser tecnicamente complexos, mas são “problemas resolvidos”.
  • Subdomínios de suporte tendem a ser simples.
  1. Volatilidade
  • Subdomínios principais mudam com frequência. Inovação constante é parte da vantagem competitiva.
  • Subdomínios genéricos podem variar ao longo do tempo, especialmente por atualizações técnicas (como correções de segurança por exemplo).
  • Subdomínios de suporte raramente mudam.
  1. Estratégia de Solução
  • Subdomínios principais devem ser implementados internamente, com os profissionais mais experientes.
  • Subdomínios genéricos, por serem problemas conhecidos, são mais econômicos de adquirir prontos (bibliotecas, serviços, ferramentas, etc).
  • Subdomínios de suporte devem ser mantidos simples e funcionais, sem investimento excessivo.

Exemplo de análise de domínio

GIGMASTER: empresa de venda e distribuição de ingressos com algoritmo de recomendação com base em serviços de streaming e redes sociais:

  • Subdomínios principais: recomendação Inteligente de Eventos;
  • Subdomínios genéricos: autenticação; contabilidade; criptografia;
  • Subdomínios suporte: Integração com serviços de streamings; integração redes sociais; gestão de eventos;

Descobrindo o Conhecimento de Domínio

Problemas de Negócio

“Problema de negócio” não significa necessariamente algo negativo, mas sim um desafio ou necessidade que existe no domínio. No processo de DDD, engenheiros de software não devem tentar se tornar especialistas do domínio, isso é responsabilidade dos especialistas de negócio.

O papel da equipe técnica é entender como esses especialistas pensam, como descrevem o problema e como classificam situações e decisões, o software deve refletir essa maneira de pensar.

O sucesso depende da qualidade da comunicação e da capacidade de transformar conhecimento em modelos explícitos. Sem compreender o problema, não é possível produzir uma solução adequada.

Comunicação

O time inteiro deve compreender e discutir o problema de negócio de maneira alinhada. Requisitos imprecisos, ambiguidades e interpretações divergentes representam riscos diretos.

O fluxo tradicional, no qual um analista de requisitos conversa com o especialista, produz um documento e repassa aos desenvolvedores, gera perdas significativas de informação. O conhecimento é filtrado, reduzido e frequentemente distorcido. DDD busca eliminar esse “telefone sem fio” por meio da colaboração contínua entre especialistas e engenheiros.

Linguagem Ubíqua

A Linguagem Ubíqua é o vocabulário compartilhado entre especialistas do domínio e equipe técnica, utilizado em todas as discussões, documentos, modelos e no próprio código.

Não é apenas um auxiliar, mas sim a principal ferramenta de alinhamento entre negócio e software. Cada termo da Linguagem Ubíqua possui um significado único eliminando ambiguidades e interpretações implícitas.

Embora frequentemente subestimada por iniciantes em DDD, a Linguagem Ubíqua é fundamental para a modelagem do domínio. É a partir dela que se tornam evidentes:

  • As fronteiras conceituais do domínio.
  • As diferenças de significado entre termos semelhantes.
  • Os pontos naturais de separação que levam à definição de Bounded Contexts.

A Linguagem Ubíqua evolui junto com o entendimento do domínio. Conforme novas descobertas são feitas, termos são refinados, descartados ou redefinidos. Essas mudanças devem ser refletidas no código e nos modelos.

O software não deve apenas implementar o domínio, mas expressar o domínio. — Vlad Khononov

Quando a Linguagem Ubíqua é corretamente aplicada, o código deixa de ser uma tradução técnica e passa a ser uma representação direta do conhecimento do negócio, reduzindo a distância entre intenção e implementação.

Exemplo de Linguagem Ubíqua correta:

  • “Pedido”, “Pagamento”, “Cancelamento”, “Cliente Recorrente”.

Exemplo que não segue a Linguagem Ubíqua:

  • “DTO de Purchase”, “ProcessPaymentHandler”, “OrderEntity” em discussões de negócio.

Uma prática comum é manter um glossário em uma wiki ou repositório compartilhado, documentando termos, significados e exemplos. Isso facilita a disseminação da Linguagem Ubíqua e reduz ambiguidades no time.

Modelo de Domínio de Negócio

A Linguagem Ubíqua se materializa por meio da modelagem de domínio. Um modelo não descreve tudo (assim como um mapa não contém cada detalhe físico do planeta), um modelo inclui intencionalmente apenas o necessário para cumprir um propósito específico dentro de um determinado contexto.

Cada modelo deve capturar apenas os elementos (conceitos, regras e comportamentos) essenciais para resolver o problema de negócio correspondente. Esses elementos são expressos utilizando a Linguagem Ubíqua, garantindo que o modelo seja compreensível, preciso e compartilhado entre especialistas do domínio e desenvolvedores.

Conforme descrito por Vlad Khononov no livro, modelos diferentes podem coexistir para o mesmo domínio, desde que atendam a propósitos distintos. Por isso, o Modelo de Domínio está sempre limitado por um contexto, reforçando a necessidade de fronteiras claras e evitando generalizações excessivas.

Administrando a Complexidade do Domínio

Modelos Inconsistentes

Em um sistema complexo, modelos diferentes podem utilizar os mesmos termos para representar conceitos diferentes. Um exemplo comum é o termo “lead”, que no contexto de marketing pode representar um contato ainda não qualificado, enquanto no contexto de vendas pode significar uma oportunidade já validada e em negociação.

Embora os termos sejam os mesmos, o significado, comportamento e o papel do conceito no processo de negócio são diferentes. Quando esses significados diferentes são tratados como se fossem o mesmo conceito, surgem ambiguidade, acoplamento indevido e modelos incoerentes. Essas inconsistências não devem ser resolvidas por meio de generalizações artificiais ou compromissos semânticos.

Contexto Delimitado (Bounded Context)

A solução proposta por DDD para este cenário é dividir a Linguagem Ubíqua em várias linguagens menores, cada uma apropriada a um contexto específico. Cada uma dessas linguagens é aplicada dentro de seu respectivo contexto delimitado.

Esse é o mecanismo central do DDD para manter a consistência dos modelos em sistemas grandes e complexos. A proposta do DDD não é forçar uma única Linguagem Ubíqua para todo o domínio, mas entender que diferentes partes do negócio exigem modelos e linguagens distintos.

Limites do Modelo

Um modelo não existe sem limites claros. Contexto Delimitado define fronteiras explícitas onde um modelo específico é válido e consistente. Dentro de um Bounded Context, cada termo possui um único significado bem definido.

A coexistência de múltiplos modelos com terminologias parecidas é aceitável dentro de um domínio, desde que estejam, de forma clara, separados por contextos e que a integração entre eles seja feita de forma explícita e controlada.

A Linguagem Ubíqua de um contexto pode ser completamente irrelevante em outro. Assim, os contextos delimitados estabelecem limites consistentes para modelos e linguagens. Essa separação permite que modelos distintos evoluam de forma independente, sem comprometer a clareza conceitual ou introduzir inconsistências semânticas.

A Relação de Unicidade: Um Modelo, Um Contexto

Para que a clareza pretendida pelo DDD seja alcançada, a relação entre o Modelo e o Contexto Delimitado deve ser, idealmente, de 1 para 1.

Muitas vezes, caímos na armadilha de tentar criar um “Modelo Único de Empresa” (como uma classe Produto ou Cliente gigante) que atenda a todos os departamentos. No entanto, no DDD estratégico, entendemos que:

  • O Modelo é o “O Quê”: Representa a lógica, as regras e os dados necessários para resolver um problema específico.
  • O Contexto Delimitado é o “Onde”: É a fronteira física e conceitual que protege esse modelo.

Por que não compartilhar modelos?

Tentar forçar um único modelo a viver em múltiplos contextos gera um acoplamento perigoso. Se o contexto de Vendas e o de Logística compartilham a mesma classe Produto, uma alteração na regra de cálculo de impostos (Vendas) pode quebrar o cálculo de cubagem de frete (Logística).

Ao respeitar o limite do Contexto Delimitado, garantimos que:

  1. Autonomia: Cada equipe pode evoluir seu modelo sem consultar outras áreas.
  2. Especialização: O modelo contém apenas o que é essencial para aquele contexto, eliminando campos irrelevantes (o “ruído”).
  3. Integridade Linguística: O termo “Produto” terá um significado técnico e de negócio exato dentro de sua fronteira, sem ambiguidades.

Dessa forma, o Contexto Delimitado atua como uma célula de proteção. O que acontece dentro dele não vaza para fora, e o que está fora não corrompe a lógica interna. A comunicação entre esses mundos diferentes não é feita compartilhando modelos, mas sim através de tradutores e mapas de contexto (Context Mapping).

Contextos Delimitados versus Subdomínios

  • Subdomínios são descobertos durante a análise do negócio.
  • Contextos delimitados são projetados durante a modelagem e o design do software.

Um subdomínio descreve uma área do negócio, já um contexto delimitado descreve a forma como essa área será representada e resolvida no software. A relação entre ambos é intencional, porém não necessariamente 1:1.

Limites

Arquitetura é basicamente sobre design de limites. Projetar um sistema implica decidir o que está dentro, o que está fora, o que é estendido e como as partes se conectam. Isso envolve compromissos, restrições e trade-offs.

No DDD, os contextos delimitados não são apenas limites conceituais, mas também funcionam como limites físicos na implementação. Cada contexto deve ser implementado como um projeto ou serviço independente.

Há também implicações organizacionais:

  • Dois times não devem ser responsáveis por um único contexto delimitado.
  • Um time pode assumir múltiplos contextos, desde que mantenha autonomia e clareza de responsabilidade.

Domínios Semânticos

Os contextos delimitados de DDD se relacionam ao conceito de domínios semânticos, definidos como áreas de significado e os termos utilizados para descrevê-las.

Esse conceito explica por que a mesma palavra pode ter significados distintos em diferentes contextos.

Exemplo clássico:

  • Na botânica, tomate é uma fruta.
  • Na culinária, tomate é um legume.

Ambas as definições são corretas dentro de seus respectivos domínios semânticos. O mesmo ocorre com modelos de software dentro de seus contextos delimitados.

Press enter or click to view image in full size

Exemplo visual do relacionamento entre os conceitos

Integrando Contextos Delimitados

Contextos delimitados não existem isoladamente. Em sistemas reais, eles precisam interagir por meio de pontos de contato formais, chamados de contratos.

DDD fornece um conjunto de padrões para definir relações e mecanismos de integração entre contextos delimitados, garantindo colaboração controlada, alinhamento conceitual e isolamento quando necessário.

As três categorias principais são:

  1. Cooperação
  2. Cliente-Fornecedor
  3. Caminhos Separados

Cooperação

Na cooperação, dois contextos delimitados trabalham juntos de forma coordenada para alcançar um objetivo comum. Os padrões tradicionais são:

  • Parceria: representa uma colaboração bidirecional, onde ambos os times assumem responsabilidade conjunta pelo sucesso da integração. Há comunicação constante, decisões compartilhadas e ajustes mútuos para manter a compatibilidade do modelo.
  • Núcleo Compartilhado: dois contextos delimitados compartilham uma parte comum do modelo. Esse núcleo deve ser estável, bem definido e de alta qualidade, pois qualquer mudança impacta diretamente mais de um time. É uma solução útil quando há forte necessidade de consistência, mas não é desejável criar um contexto único.

Cliente-Fornecedor

Nesta categoria, um contexto atua como cliente e outro como fornecedor. A relação é unilateral e o fornecedor define o contrato a ser consumido. Os principais padrões são:

  • Conformista: o cliente depende totalmente do fornecedor e deve se adaptar ao modelo e às decisões dele. É usado quando o fornecedor é dominante ou não é possível influenciar seu design. É comum em integrações com sistemas legados ou externos.
  • Camada Anticorrupção: o cliente protege seu modelo criando uma camada intermediária que traduz modelos, formatos e semânticas entre os contextos. Essa camada impede que inconsistências conceituais do fornecedor contaminem o modelo do cliente.
  • Serviço de Host Aberto: o fornecedor disponibiliza uma interface formal, clara e estável para consumo externo. Essa interface representa o contrato do fornecedor, permitindo que múltiplos clientes o utilizem sem necessidade de dependência direta do modelo interno do contexto fornecedor.

Caminhos Separados

Representa a ausência de colaboração significativa. Os times não querem ou não podem cooperar diretamente. Isso ocorre quando:

  • Problemas na Comunicação: as equipes não conseguem se alinhar, seja por restrições organizacionais, disponibilidade limitada ou conflitos de prioridade.
  • Subdomínios Genéricos: quando o contexto é genérico, não faz sentido investir em colaboração profunda. Cada time pode implementar ou adquirir sua própria solução sem impacto estratégico.
  • Diferenças de Modelo: os modos de pensar, representar e resolver o problema são tão distintos que não compensa conciliar os modelos. Contextos seguem caminhos independentes para evitar esforço excessivo e perda de produtividade.

Mapas de Contexto (Context Mapping)

Os mapas de contexto representam visualmente as relações entre contextos delimitados e os padrões de integração adotados. Entre suas vantagens estão:

  • Claridade sobre limites, responsabilidades e dependências.
  • Facilitação da manutenção e evolução arquitetural.
  • Identificação de problemas recorrentes, como acoplamentos fortes ou dependências críticas.
  • Melhor entendimento organizacional sobre como os times se relacionam.

Ao mesmo tempo, mapas de contexto têm limitações: não capturam todos os detalhes operacionais e precisam ser atualizados regularmente para refletir mudanças na arquitetura ou na estrutura das equipes.

Context Mapping

Conclusão

Neste artigo tentei abordar de forma clara os principais conceitos que compõem o Design Estratégico no Domain-Driven Design, incluindo domínios, subdomínios, tipos de subdomínios, linguagem ubíqua, modelos, contexto delimitado e mapas de contexto.

O Design Estratégico é o que permite projetar sistemas mais fáceis de evoluir e manter. Com ele você estabelece limites claros, responsabilidades bem definidas e uma linguagem comum que permeia todo o desenvolvimento. Ignorar essa etapa e partir diretamente para o código pode resultar em soluções acopladas, difíceis de entender e custosas de modificar.

Como dito na introdução, devido ao termo “design”, é comum achar que DDD nada mais é do que técnicas para escrever código. No entanto, ao iniciar os estudos em DDD, fica claro que o core dele está na parte estratégica. Ela orienta a construção de sistemas alinhados ao domínio, reduzindo ambiguidades, facilitando a comunicação entre áreas técnicas e de negócio e tornando as regras de negócio mais explícitas, compreensíveis e sustentáveis ao longo do tempo.

O livro de Vlad com certeza foi uma leitura que mudou a forma como eu olho para os “problemas” de negócio, muitos dos desafios em software não são técnicos, mas sim conceituais e organizacionais.