DDD: Características e tipos de relacionamento

Neste artigo iremos tratar das principais características do DDD.

1. Foco no Domínio

O desenvolvimento parte do entendimento profundo do problema de negócio, e não da tecnologia.

Exemplo: Uma fintech desenvolve um sistema de concessão de crédito. O time de desenvolvimento deve entender conceitos como score, inadimplência, limites e garantias antes de escrever código.

2. Modelo de Domínio

Trata-se de uma estrutura conceitual que representa os principais elementos, regras e interações do domínio.

Exemplo: No sistema de crédito, o modelo inclui Cliente, PropostaDeCrédito, AnáliseDeRisco, Garantia. Esses elementos formam a base lógica do sistema.

3. Linguagem Ubíqua

Todos os envolvidos no projeto usam a mesma terminologia, seja no código, documentação ou reuniões.

Exemplo: Termos como “limite aprovado”, “garantia real” e “inadimplência” são usados com o mesmo significado tanto pelos analistas financeiros quanto pelos desenvolvedores.

4. Bounded Context (Contexto Delimitado)

O domínio é dividido em áreas independentes, cada uma com sua definição de termos, regras e lógica.

Exemplo: No sistema da fintech, o termo Cliente pode significar uma pessoa física no contexto de crédito pessoal e um CNPJ no contexto de crédito empresarial. Cada contexto é isolado.

5. Entidades

Objetos com identidade única e ciclo de vida contínuo, que representam conceitos centrais do negócio.

Exemplo: Um ContratoDeCrédito tem um número único, passa por fases como análise, aprovação e liquidação, mas continua sendo o mesmo contrato.

6. Objetos de Valor

Objetos imutáveis e sem identidade própria, definidos apenas por seus atributos.

Exemplo: A FaixaDeRenda de um cliente com atributos “de R$2.000 a R$5.000” é um valor. Duas faixas com os mesmos valores são consideradas iguais.

7. Serviços

Representam operações do domínio que não pertencem diretamente a uma entidade ou objeto de valor.

Exemplo: Um serviço SimuladorDeParcelas calcula valores de parcelas para diferentes prazos e taxas. Ele utiliza dados de várias entidades, mas não pertence a nenhuma isoladamente.

Independência Tecnológica

O domínio deve ser modelado sem dependência de frameworks ou tecnologias específicas.

Exemplo: A lógica de negócios que aprova uma proposta de crédito não deve depender de banco de dados, REST, mensageria ou ORM. Ela pode ser testada isoladamente.

Reutilização e Mínimo Acoplamento

A estrutura facilita a reutilização de componentes e evita dependências desnecessárias entre módulos.

Exemplo: O módulo de análise de crédito pode ser reutilizado em outro produto da empresa (por exemplo, cartão de crédito) com poucas adaptações.

10. Colaboração com Especialistas de Domínio

A construção do modelo exige diálogo contínuo com quem entende o negócio.

Exemplo: Desenvolvedores participam de reuniões semanais com analistas de risco para entender critérios usados na avaliação de crédito e ajustá-los ao sistema.

QUESTÃO INÉDITA

Acerca da abordagem do Domain Driven Design (DDD), julgue o item a seguir:

A aplicação do DDD pressupõe a divisão do domínio em contextos delimitados, conhecidos como bounded contexts, nos quais os termos e conceitos são utilizados de maneira consistente. Essa prática permite que o mesmo termo possa ter significados distintos em diferentes partes do sistema, sem gerar ambiguidade ou conflitos, contribuindo para um alinhamento mais eficaz entre o negócio e o código-fonte.

Comentário:

O bounded context é um dos conceitos centrais do DDD. Ele define limites explícitos dentro do sistema, onde um modelo específico é válido e onde a linguagem ubíqua é aplicada com precisão. Isso permite que o mesmo termo (como “Cliente”, “Produto” ou “Pedido”) tenha significados distintos em contextos diferentes, sem gerar ambiguidade.

Gabarito está correto.

Principais Tipos de Relacionamento entre Bounded Contexts

QUESTÃO INÉDITA

Sobre os tipos de relacionamento entre Bounded Contexts no Domain Driven Design (DDD), assinale a opção correta.

A) No relacionamento Conformist, ambos os contextos compartilham explicitamente partes do modelo e da linguagem ubíqua, exigindo alinhamento constante entre os times.

B) O relacionamento Anti-Corruption Layer envolve a adaptação do modelo de um contexto para o outro, permitindo que o contexto consumidor preserve seu próprio modelo conceitual.

C) O relacionamento Customer–Supplier ocorre quando dois contextos seguem caminhos distintos, sem nenhuma dependência entre si.

D) No relacionamento Shared Kernel, um dos contextos impõe seu modelo ao outro, que se adapta a ele sem poder influenciar sua estrutura.

E) O relacionamento Separate Ways exige sincronização constante entre os contextos envolvidos, pois eles evoluem de forma colaborativa e integrada.

Comentário:

• Letra A – Errada: Essa definição descreve o Shared Kernel, mas o enunciado atribui erroneamente ao Conformist.
• Letra B – Correta: O Anti-Corruption Layer protege o modelo de um contexto ao isolar e adaptar interações com outros contextos, preservando sua integridade.
• Letra C – Errada: Esse é o conceito de Separate Ways, não de Customer–Supplier.
• Letra D – Errada: Essa é a definição de Conformist, e não de Shared Kernel.
• Letra E – Errada: Esse comportamento está relacionado ao Partnership, não ao Separate Ways.

Gabarito é a letra B.

Ano: 2023 Banca: CESPE / CEBRASPE Órgão: SERPRO
Prova: CESPE / CEBRASPE – 2023 – SERPRO – Analista – Especialização: Tecnologia

Com relação a design de software, julgue o item a seguir.

Em DDD (Domain-Driven Design), ubiquitous language representa o jargão utilizado no domínio projeto, que deve ser entendido completamente pela área de negócio e pela equipe de desenvolvimento.

Comentário:
A linguagem ubíqua (ubiquitous language) é um dos pilares do Domain-Driven Design (DDD). Ela consiste em uma linguagem comum, baseada no domínio de negócio, que deve ser usada por todos os membros da equipe (desenvolvedores, analistas, especialistas do domínio) para evitar ambiguidades e garantir entendimento compartilhado. Essa prática fortalece a comunicação e alinha o modelo de software ao modelo do negócio.

Gabarito está CORRETO.

Ano: 2024 Banca: FGV Órgão: CVM Prova: FGV – 2024 – CVM – Analista CVM – Perfil 8 – TI / Sistemas e Desenvolvimento – Tarde

A Equipe de Desenvolvimento de Soluções de Software (EDSS) recebeu a demanda de desenvolvimento de um software complexo e, por isso, pretende utilizar a abordagem Domain Driven Design (DDD).

Com foco no modelo de domínio principal, a EDSS assumirá que:

A) a lógica da aplicação deve considerar o modo de persistência de objetos nos repositórios;
B) as entidades serão definidas pelos atributos que as descrevem;
C) os analistas de negócio e de requisitos serão os responsáveis pela definição da Linguagem Ubíqua;
D) os objetos do domínio serão modelados com responsabilidades do próprio armazenamento, mas não da própria exibição;
E) uma operação deve ser adicionada ao modelo como uma interface autônoma, declarada como um serviço, quando não for uma responsabilidade natural de uma Entidade ou de um Objeto de Valor.

Comentário:

No DDD, quando uma operação não se encaixa naturalmente em uma entidade ou objeto de valor, ela deve ser modelada como um Serviço de Domínio. Serviços são interfaces explícitas, sem estado, que encapsulam comportamentos do domínio. Essa prática mantém o modelo coeso e evita a sobrecarga de responsabilidades em entidades. As demais alternativas estão em desacordo com os princípios do DDD, especialmente ao confundir persistência com domínio (A), reduzir entidades a atributos (B), delegar definição da linguagem ubíqua a um grupo restrito (C), ou atribuir responsabilidades de infraestrutura ao modelo de domínio (D).

Gabarito é a letra E.