DOMAIN DRIVEN DESIGN (DDD)

O Domain Driven Design (DDD), ou Design Orientado ao Domínio, é uma abordagem estratégica e tática usada para modelar software baseado em realidades de negócios complexas. Desenvolvida por Eric Evans, a abordagem tem como objetivo alinhar o modelo de software com o domínio do problema, ou seja, com aquilo que o sistema pretende resolver.

Três premissas fundamentais do DDD

1. Foco no Domínio Principal
   O projeto deve se concentrar no núcleo do problema, ou seja, na área de conhecimento específica que se pretende automatizar.
2. Modelagem baseada no Domínio
   Todo o projeto é estruturado sobre um modelo do domínio, que representa conceitos, regras e comportamentos do negócio.
3. Colaboração ativa entre especialistas do domínio e equipe técnica
   Para refinar o modelo conceitual, é essencial a troca contínua entre desenvolvedores e especialistas do negócio.

Conceitos Fundamentais

🔹 O que é Domínio?

É o assunto principal do problema que se deseja resolver com software. Por exemplo: saúde, finanças, justiça, logística, etc.

🔹 O que é Modelo?

É uma abstração estruturada que representa os elementos mais importantes do domínio. Ele serve de base para o código-fonte do sistema.

Colaboração e Processo Iterativo

• O DDD não funciona em isolamento. É necessário:
  • Equipe experiente em orientação a objetos.
  • Especialistas do negócio ativamente envolvidos.
  • Um processo iterativo e incremental, que evolui com o entendimento progressivo do domínio.

Linguagem Ubíqua

Um dos pilares mais importantes do DDD é a Linguagem Ubíqua, ou seja, uma linguagem comum que deve:

• Ser usada por todos (devs, analistas, clientes) em reuniões, análises, código e documentação.
• Ser precisa e sem ambiguidade.
• Refletir diretamente os conceitos do modelo do domínio.
• Unificar vocabulário técnico e de negócio, promovendo clareza e consistência.

Exemplo:

Se o domínio for Justiça, termos como “promotor”, “intimação”, “autos”, “prazo legal” devem estar presentes tanto nas conversas quanto no código, como nomes de classes, métodos e entidades.

Questão Inédita 

Acerca dos fundamentos do Domain Driven Design (DDD), julgue o item a seguir:

No DDD, o modelo do domínio é construído exclusivamente pela equipe técnica com base em requisitos previamente definidos pelos especialistas, não sendo necessária a participação contínua destes durante o desenvolvimento.

COMENTÁRIO

O DDD exige colaboração contínua entre técnicos e especialistas do domínio para refinamento do modelo.

Gabarito: Errado

Alinhamento entre Software e Domínio

O DDD parte da premissa de que software de qualidade só pode ser construído quando está profundamente conectado ao domínio do problema. Isso significa que o sistema deve refletir, com precisão, as regras, estruturas e comportamentos observados na área de atuação da organização.

A compreensão do domínio precisa acontecer por meio de interações frequentes com os especialistas de negócio, pois eles detêm o conhecimento necessário para modelar o sistema de forma eficaz.

Relação entre Domínio e Software

• O domínio é a área de conhecimento (por exemplo, seguros, justiça, saúde) sobre a qual o software será construído.
• Os especialistas do domínio são as pessoas que vivenciam esse conhecimento no dia a dia (ex: analistas de seguro, promotores de justiça, médicos).
• Os desenvolvedores são especialistas em outro domínio: o desenvolvimento de software.

DDD faz a ponte entre esses dois mundos, permitindo que o conhecimento seja incorporado ao software de maneira estruturada e precisa.

A importância das Regras de Negócio

Todo o conhecimento adquirido nas conversas com os especialistas precisa ser transformado em algo implementável no código-fonte. Essa transformação ocorre por meio das regras de negócio, que:

• Representam comportamentos e decisões do domínio.
• São a base para a implementação de funcionalidades no sistema.
• Garantem que o sistema reaja corretamente às mudanças no negócio.

Resumo dos Fundamentos

• O DDD não é uma técnica para escrever código rapidamente, mas para estruturar software em domínios complexos com alto alinhamento ao negócio.
• Exige colaboração constante entre times técnicos e especialistas de negócio.
• O modelo criado deve ser capaz de evoluir junto com o negócio, sendo robusto e adaptável.
• As Regras de Negócio são a principal expressão do domínio no código-fonte.

Questão Inédita 

Em relação ao Domain Driven Design (DDD), assinale a alternativa correta:

a) O domínio deve ser modelado com base exclusivamente nos requisitos documentados previamente pelos analistas de sistemas.
b) O uso de frameworks específicos é essencial para o correto funcionamento da abordagem DDD.
c) A linguagem ubíqua deve ser restrita à equipe de desenvolvimento, evitando ambiguidade técnica.
d) O modelo do domínio deve refletir os conceitos, elementos e comportamentos reais da área de negócio.
e) As regras de negócio devem ser mantidas em documentação externa, não no próprio sistema.

Gabarito é a letra D.

O DDD exige que o software seja projetado com base em um modelo do domínio que reflete o conhecimento do negócio, incorporando conceitos e comportamentos reais.

Agora algumas questões retiradas de provas.

01 Ano: 2023 Banca: FGV Órgão: SEFAZ-MG Prova: FGV – 2023 – SEFAZ-MG – Auditor Fiscal da Receita Estadual – Tecnologia da Informação (Tarde)
Em domain-driven design (DDD), a linguagem ubíqua ou linguagem onipresente é um conceito central.
Assinale a opção que indica seu principal objetivo.

A) Documentar o domínio.
B) Providenciar um meio de comunicação com os especialistas do domínio.
C) Facilitar a comunicação entre especialistas e desenvolvedores.
D) Criar uma linguagem compartilhada que é usada durante o processo de desenvolvimento.
E) Criar convenções de nomenclatura.

Comentário:
A linguagem ubíqua no DDD tem como objetivo criar uma linguagem comum e precisa, usada por todos (desenvolvedores, analistas, especialistas de negócio) durante o desenvolvimento de software. Essa linguagem deve ser empregada em código, testes, documentação e discussões, promovendo entendimento e alinhamento entre todas as partes envolvidas.

Gabarito é a letra D.

02 Ano: 2025 Banca: FGV Órgão: DPE-RO Prova: FGV – 2025 – DPE-RO – Analista de Sistemas – Classe B

Design Orientado por Domínio (ou DDD, Domain Driven Design) é uma metodologia de desenvolvimento de software que visa criar um modelo de software que corresponda ao domínio de negócios. Com relação a Design Orientado por Domínio, analise os itens a seguir:

I. O DDD se opõe à ideia de ter um único modelo para todo o sistema; em vez disso, incentiva a divisão do sistema em contextos limitados, cada um dos quais tem seu próprio modelo.
II. Durante a fase estratégica de DDD, você está mapeando fora do domínio empresarial e definindo contextos limitados para seus modelos de domínio.
III. DDD tático é quando você define os modelos de domínio com mais precisão, sendo estes padrões aplicados dentro de um único contexto limitado.

Está correto o que se afirma em:
A) I, apenas.
B) II, apenas.
C) III, apenas.
D) I e III, apenas.
E) I, II e III.

Comentário:

• Item I – Correto: DDD realmente incentiva a divisão do sistema em Bounded Contexts, cada um com um modelo próprio. Isso evita a complexidade de um modelo único e monolítico.
• Item II – Correto: A fase estratégica do DDD trata de mapear os domínios, identificar subdomínios e definir os Bounded Contexts, o que envolve delimitar onde e como os modelos serão aplicados.
• Item III – Correto: A fase tática do DDD foca na definição dos modelos dentro de um Bounded Context, utilizando padrões como Entidades, Objetos de Valor, Agregados, Repositórios, etc.

Gabarito é a letra E.

03 Ano: 2024 Banca: Instituto Access Órgão: UFAPE  Prova: Instituto Access – 2024 – UFAPE – Analista de TI – Área: Análise de Sistemas, Governança, Rede e Suporte

TDD, DDD e BDD são três padrões de qualidade de desenvolvimento de software que enfatizam abordagens diferentes, mas complementares, para garantir a qualidade e a eficácia do processo de desenvolvimento. A esse respeito, analise as afirmativas a seguir:

I. BDD é uma abordagem de design de software que se concentra em modelar o domínio de um problema complexo de negócios em termos de entidades de domínio, serviços e agregados.
II. TDD é uma abordagem de desenvolvimento de software que enfatiza escrever testes automatizados antes de escrever o código de produção.
III. O objetivo do DDD é garantir que o software seja desenvolvido com base nos requisitos e comportamentos desejados do sistema, resultando em uma compreensão clara das expectativas do sistema e na validação contínua do comportamento conforme o desenvolvimento avança.

Comentário:

• Item I – Incorreto
  A definição está errada porque ela descreve o DDD, mas atribui erroneamente essa descrição ao BDD.
  → Erro conceitual grave.
• Item II – Correto
  Essa é a definição correta do TDD (Test-Driven Development).
  → Perfeito.
• Item III – Incorreto
  Apesar de parecer verdadeira à primeira vista, a frase mistura a finalidade do BDD com termos do DDD, causando confusão conceitual. O DDD é centrado no modelo do domínio, e não tem como foco principal a validação contínua do comportamento com testes. Isso é característica do BDD.
  → Erro técnico disfarçado.

Gabarito é a letra B.