Domain-Driven Design: resumo e questões sobre DDD

Por
Publicado em
4 min. de leitura

O DDD Estratégico é uma das partes mais cobradas quando o assunto é Domain-Driven Design. As bancas costumam explorar principalmente os conceitos de Domínio, Subdomínios, Core Domain, Supporting Subdomain, Generic Subdomain, Bounded Context e Linguagem Ubíqua.

Terças e quintas de TI. Conteúdo prático e artigos especializados para acelerar seu conhecimento. Acesse agora!

Domínio

O domínio representa a área de negócio que o software pretende resolver.

É o conjunto de regras, processos, conhecimentos e problemas de determinada organização.

Exemplos:

  • Banco → domínio financeiro.
  • Hospital → domínio de saúde.
  • E-commerce → domínio de vendas.

Uma definição muito comum em provas é: domínio é o conhecimento relacionado ao problema que o software busca solucionar.

Subdomínios

Como os domínios costumam ser complexos, eles são divididos em partes menores chamadas subdomínios.

O DDD classifica os subdomínios em três tipos.

Core Domain (Domínio Principal)

É o conceito mais cobrado em provas.

Representa a parte mais estratégica do negócio.

É o que gera vantagem competitiva para a organização.

Características:

  • Maior valor para a empresa.
  • Diferencial competitivo.
  • Recebe maior investimento.
  • Contém as regras mais importantes.

Exemplo

Em uma fintech:

  • Motor de análise de crédito.
  • Algoritmo antifraude.

Esses componentes podem representar o Core Domain.

Como a banca costuma cobrar

Afirmar que:

Core Domain é a parte mais importante do negócio e responsável pela vantagem competitiva da organização.

Item correto.

Supporting Subdomain (Subdomínio de Apoio)

São funcionalidades importantes para o negócio, mas que não representam o diferencial competitivo.

Características:

  • Possuem regras específicas.
  • Apoiam o domínio principal.
  • Não são o foco estratégico.

Exemplo

Em uma fintech:

  • Cadastro de clientes.
  • Gestão de contratos.

São necessários, mas não representam o diferencial da empresa.

Pegadinha comum

A banca troca Core por Supporting.

Se o enunciado mencionar:

Diferencial competitivo.

Normalmente está falando de Core Domain.

Generic Subdomain (Subdomínio Genérico)

São funcionalidades comuns a diversas empresas.

Normalmente podem ser compradas prontas.

Características:

  • Não geram vantagem competitiva.
  • São amplamente reutilizáveis.
  • Frequentemente adquiridas de terceiros.

Exemplo

  • Login.
  • Controle de acesso.
  • Envio de e-mails.
  • Auditoria.
  • Emissão de relatórios.

Como aparece em provas

Questões costumam afirmar:

Generic Subdomain representa funcionalidades genéricas compartilhadas por diversas organizações.

Item correto.

Bounded Context (Contexto Delimitado)

É o conceito mais importante do DDD Estratégico.

Um Bounded Context define um limite dentro do qual determinado modelo possui significado único.

Em outras palavras:

Dentro de um contexto, os termos possuem um único significado.

Exemplo clássico

Imagine um sistema de e-commerce.

O termo “Cliente” pode significar:

Contexto Comercial

Cliente = pessoa que compra produtos.

Contexto Financeiro

Cliente = pessoa que possui débitos, créditos e faturas.

É o mesmo termo, mas com significados diferentes.

O DDD recomenda separar esses modelos em Contextos Delimitados distintos.

Como a banca costuma cobrar

Questões frequentemente afirmam:

O mesmo conceito pode possuir significados distintos em diferentes Bounded Contexts.

Item correto.

Relação entre Subdomínio e Bounded Context

Esse é um dos pontos favoritos das bancas.

Muitos candidatos confundem os conceitos.

Subdomínio

Visão de negócio.

Responde:

Qual parte do negócio estamos tratando?

Exemplo:

  • Pagamentos.
  • Clientes.
  • Estoque.

Bounded Context

Visão de modelagem.

Responde:

Em qual contexto esse modelo possui significado?

Linguagem Ubíqua (Ubiquitous Language)

Outro conceito muito explorado em provas.

Consiste em utilizar uma linguagem comum entre:

  • Desenvolvedores.
  • Analistas.
  • Testadores.
  • Especialistas de negócio.

Todos devem usar os mesmos termos.

Exemplo

Se o negócio utiliza o termo:

“Proposta de Crédito”

Toda a equipe deve utilizar exatamente esse termo.

Não deve existir:

  • Solicitação.
  • Pedido.
  • Requisição.

Cada nome diferente gera ambiguidade.

Questões inéditas

01 Em uma organização que utiliza Domain-Driven Design (DDD), os gestores identificaram que o sistema possui módulos responsáveis pelo algoritmo de precificação dinâmica, cadastro de clientes, autenticação de usuários e emissão de relatórios gerenciais.

Considerando a classificação dos subdomínios no DDD Estratégico, assinale a alternativa correta.

A) O cadastro de clientes necessariamente representa o Core Domain da organização.

B) A autenticação de usuários e a emissão de relatórios são exemplos típicos de Generic Subdomains.

C) O algoritmo de precificação dinâmica deve ser classificado como Supporting Subdomain.

D) Todo Generic Subdomain possui maior relevância estratégica que o Core Domain.

E) Supporting Subdomains não possuem regras de negócio próprias.

Comentário

O Core Domain representa o diferencial competitivo da organização. Já funcionalidades comuns a diversas empresas, como autenticação, controle de acesso e relatórios, costumam ser classificadas como Generic Subdomains.

A) Errada. Cadastro de clientes normalmente é um Supporting Subdomain.

B) Correta. Login, autenticação e relatórios são exemplos clássicos de Generic Subdomains.

C) Errada. Um algoritmo de precificação dinâmica tende a representar o Core Domain.

D) Errada. O Core Domain é o mais estratégico.

E) Errada. Supporting Subdomains possuem regras próprias, embora não sejam o diferencial competitivo.

Gabarito: Letra B.

02 No contexto do Domain-Driven Design (DDD), considere as afirmativas abaixo acerca dos Bounded Contexts.

I. Um mesmo termo pode possuir significados distintos em diferentes Bounded Contexts.

II. Cada Bounded Context define um limite dentro do qual determinado modelo possui significado específico.

III. O objetivo do Bounded Context é eliminar completamente a existência de múltiplos modelos para um mesmo domínio.

Está correto o que se afirma em

A) I, apenas.

B) I e II, apenas.

C) II e III, apenas.

D) III, apenas.

E) I, II e III.

Comentário

I) Correta. Um mesmo conceito pode assumir significados diferentes em contextos distintos.

II) Correta. Essa é exatamente a definição de Bounded Context.

III) Errada. O DDD aceita múltiplos modelos para um mesmo domínio, desde que estejam claramente delimitados por contextos.

Gabarito: Letra B.

03 A respeito dos conceitos de Linguagem Ubíqua, Domínio e Subdomínios no Domain-Driven Design (DDD), assinale a alternativa correta.

A) A Linguagem Ubíqua deve ser utilizada exclusivamente pela equipe de desenvolvimento.

B) O domínio representa a tecnologia utilizada para implementação da solução.

C) A Linguagem Ubíqua busca estabelecer termos distintos para cada área técnica envolvida no projeto.

D) O domínio corresponde ao conjunto de conhecimentos, regras e processos relacionados ao problema que o software pretende resolver.

E) Os subdomínios existem apenas para dividir tecnicamente o código-fonte da aplicação.

Comentário

O domínio representa a área de negócio que o software busca atender. A Linguagem Ubíqua deve ser compartilhada entre especialistas de negócio e equipe técnica para evitar ambiguidades.

A) Errada. Deve ser utilizada por todos os envolvidos no projeto.

B) Errada. Domínio está relacionado ao negócio, não à tecnologia.

C) Errada. O objetivo é unificar a linguagem, e não criar terminologias diferentes.

D) Correta. Essa é a definição clássica de domínio em provas de concurso.

E) Errada. Os subdomínios representam divisões do negócio, e não apenas do código.

Gabarito: Letra D.

QUADRO COMPARATIVO COM OUTROS MÉTODOS

DDD x MDA x MDD x FDD

Aspecto / AbordagemFDDMDA)MDD DDD 
Foco PrincipalFuncionalidades (features) de valor para o clienteTransformações automatizadas de modelos até o códigoDesenvolvimento orientado por modelos abstratosModelo do domínio e regras de negócio
Tipo de AbordagemÁgil híbrido (entre XP e RUP)Arquitetural baseada em modelosEngenharia de software com abstração elevadaOrientada a objetos com foco em colaboração com negócio
Unidade de TrabalhoFeature (pequena funcionalidade)Modelo → CódigoModelo → CódigoConceitos do domínio e regras de negócio
Fases ou Ciclo2 fases: Planejamento e Construção (com 5 processos)PIM → PSM → CódigoModelagem → Geração de códigoIterativo: modelagem colaborativa e evolução contínua
Colaboração com negócioParticipação do cliente com visibilidadeLimitada, foco técnicoParcial, foco na modelagemForte, com uso de linguagem ubíqua e especialistas
DocumentaçãoLista de funcionalidades e modelos de classeModelos formais (UML) transformados em códigoModelos descritivos e documentaisDocumentação dinâmica, alinhada ao modelo do domínio
Exemplos-chaveCadastro de cliente, relatórios, funcionalidades visíveisSistema gerado via ferramenta a partir de UMLModelagem de sistemas em BPMN/UML com geração de códigoSoftware de gestão bancária com conceitos como Cliente, Conta
Ferramentas típicasModelagem de objetos, inspeções e buildsFerramentas de transformação de modelos (ex: EMF, UML)Ferramentas de modelagem + geração automáticaUso de entidades, repositórios, serviços, linguagem ubíqua
BenefíciosEntregas rápidas, visibilidade e rastreabilidadeProdutividade com foco em reutilização e automaçãoAumento da abstração, comunicação e produtividadeBaixo acoplamento, código coeso e alinhado ao negócio
DesvantagensPouca adaptabilidade a mudanças frequentesAlto custo inicial e dependência de ferramentasCurva de aprendizado e dependência de ferramentasComplexidade inicial e necessidade de forte integração

Por
Publicado em
4 min. de leitura

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *