Domain Driven Design – Principais Características

Por Gunter Amorim

xx de Setembro de 2025 – 9 min. de leitura

Saudações, futuro(a) aprovado(a)! Professor Gunter Amorim aqui.

No mundo do desenvolvimento de software, a complexidade dos sistemas tem crescido exponencialmente. É aí que entra o Domain Driven Design (DDD), uma abordagem de design que foca no domínio (o negócio, a área de atuação do sistema). O DDD não é uma tecnologia ou um framework, mas sim um conjunto de princípios e padrões que guiam a modelagem de softwares complexos, garantindo que o código reflita a lógica de negócio de forma clara e precisa. Nos concursos, questões sobre DDD têm se tornado cada vez mais comuns, especialmente em provas de alto nível. Vamos dominar os conceitos chave!

A Filosofia do DDD

A ideia central do DDD é que o software deve ser construído em torno de um modelo de domínio, um sistema de conceitos que descreve o problema de negócio a ser resolvido. Para isso, a comunicação entre especialistas de negócio e desenvolvedores é crucial.

Os principais pilares do DDD são:

1. Linguagem Ubíqua (Ubiquitous Language)

A Linguagem Ubíqua é um vocabulário comum e consistente usado por toda a equipe (desenvolvedores, gerentes de projeto, especialistas do negócio). Cada conceito e termo no sistema de software deve corresponder exatamente a um termo do negócio, sem ambiguidades.

Exemplo: Se a equipe de vendas chama um pedido de Venda, os desenvolvedores devem usar a classe Venda em vez de Pedido ou Transacao. A consistência evita mal-entendidos e garante que o modelo de software seja um reflexo fiel do negócio.

2. Contexto Delimitado (Bounded Context)

Um Contexto Delimitado define os limites lógicos e de responsabilidade de um modelo de domínio. Dentro de cada contexto, a Linguagem Ubíqua é consistente. Fora dele, os termos podem ter significados diferentes. É a principal ferramenta para lidar com a complexidade de sistemas grandes.

Exemplo: Em um sistema de e-commerce, o conceito de Produto no Contexto de Vendas pode ter um Preco e uma Disponibilidade. Já no Contexto de Logística, o mesmo Produto pode ter um Peso e Dimensões para o cálculo do frete. São modelos diferentes do mesmo “objeto” que fazem sentido em seus respectivos contextos.

3. Entidades (Entities)

Uma Entidade é um objeto de domínio que possui uma identidade única e que persiste ao longo do tempo. Sua identidade é o que a diferencia de outras entidades, independentemente de seus atributos.

Exemplo: Uma classe Cliente é uma Entidade. O cliente João da Silva, de CPF 123.456.789-00, é a mesma pessoa, mesmo que ele mude seu endereço, telefone ou e-mail. A identidade (geralmente um id) é o que importa.

4. Objetos de Valor (Value Objects)

Um Objeto de Valor é um objeto que não tem identidade única. Ele é definido inteiramente por seus atributos e é imutável. Se dois Objetos de Valor têm os mesmos atributos, eles são considerados o mesmo objeto.

Exemplo: Uma classe Endereco. Um endereço com “Rua A, 123, Cidade B” é o mesmo, não importa onde ele seja usado. Seus atributos (rua, número, cidade) o definem. Outros exemplos incluem Dinheiro, Data e Cor.

5. Agregados (Aggregates)

Um Agregado é um cluster de Entidades e Objetos de Valor que é tratado como uma única unidade. Cada Agregado tem uma raiz, a qual é a única Entidade que pode ser acessada diretamente de fora do Agregado. A consistência dos dados do Agregado é garantida por essa raiz.

Exemplo: Em um sistema de pedidos, a Entidade Pedido pode ser a raiz de um Agregado que inclui os Objetos de Valor Endereco e as Entidades ItemDePedido. Para modificar um ItemDePedido, você deve sempre passar pela raiz Pedido, garantindo que todas as regras de negócio relacionadas a ele sejam aplicadas.

DDD e a Arquitetura de Microsserviços

Uma das principais razões para o DDD ganhar tanta força é sua sinergia com a arquitetura de microsserviços. Em muitos casos, um Contexto Delimitado serve como um blueprint natural para um microsserviço. Isso ajuda a manter os serviços pequenos, coesos e com responsabilidades bem definidas, reduzindo o acoplamento entre eles.

Bora ver como esse assunto é cobrado nas provas!

1. (CEBRASPE/AUDITOR/SEFAZ-RJ/2025)

No DDD (domain-driven design), a linguagem ubíqua é

1. um conjunto de termos e regras comuns.
2. uma linguagem de programação.
3. uma estrutura para tomada de decisão.
4. um conjunto de diagramas de componentes.
5. uma linguagem gráfica para documentação.

COMENTÁRIO

A alternativa correta é a A. No DDD (Domain-Driven Design), a linguagem ubíqua é um conjunto de termos e regras comuns que são compartilhados e utilizados de forma consistente por todos os membros da equipe (desenvolvedores, especialistas de domínio e gerentes) para descrever o modelo do domínio. O objetivo é eliminar ambiguidades e garantir que a comunicação seja clara e que o código reflita com precisão os conceitos de negócio.

2. (CEBRASPE/ANALISTA/MPO/2024)

A respeito de arquitetura de aplicações, julgue o próximo item.

Em DDD (domain-driven design), a linguagem Ubiquitous é utilizada para a codificação dos módulos da aplicação.

COMENTÁRIO

A afirmação está errada. Embora a linguagem ubíqua seja a base para o modelo de domínio que será implementado no código, a interpretação do gabarito é de que sua principal função não é a codificação em si, mas sim servir como uma linguagem comum e universal. Ela permite que todos os profissionais envolvidos no processo de desenvolvimento, de diferentes áreas, possam se comunicar e se entender sobre o domínio do negócio de forma consistente e sem ambiguidades, sendo, portanto, um conceito central para a comunicação e o entendimento do processo, e não um propósito exclusivo para a codificação.

3. (FGV/AUDITOR/SEF-MG/2023)

Em domain-driven design (DDD), a linguagem ubíqua ou linguagem onipresente é um conceito central.

Assinale a opção que indica seu principal objetivo.

1. Documentar o domínio.
2. Providenciar um meio de comunicação com os especialistas do domínio.
3. Facilitar a comunicação entre especialistas e desenvolvedores.
4. Criar uma linguagem compartilhada que é usada durante o processo de desenvolvimento.
5. Criar convenções de nomenclatura.

COMENTÁRIO

A alternativa correta é a D. O principal objetivo da linguagem ubíqua ou onipresente em Domain-Driven Design (DDD) é criar um vocabulário comum e compartilhado que seja usado de forma consistente por todos os envolvidos no projeto, incluindo desenvolvedores, analistas de negócio e especialistas de domínio. Essa linguagem unificada é a base para a comunicação, a modelagem e a implementação, garantindo que o entendimento do domínio seja o mesmo para todos ao longo de todo o processo de desenvolvimento.

Conclusão

O DDD oferece um mapa para navegar pela complexidade do software, colocando o domínio de negócio no centro de tudo. Entender conceitos como Linguagem Ubíqua, Contexto Delimitado, Entidades, Objetos de Valor e Agregados é o primeiro passo para construir sistemas de forma mais inteligente. Para sua aprovação, essa é uma área de conhecimento que te diferencia, mostrando que você não está apenas preocupado com o código, mas com a arquitetura e a qualidade do software como um todo.

Sucesso na sua jornada!