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.

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 / Abordagem | FDD | MDA) | MDD | DDD |
| Foco Principal | Funcionalidades (features) de valor para o cliente | Transformações automatizadas de modelos até o código | Desenvolvimento orientado por modelos abstratos | Modelo do domínio e regras de negócio |
| Tipo de Abordagem | Ágil híbrido (entre XP e RUP) | Arquitetural baseada em modelos | Engenharia de software com abstração elevada | Orientada a objetos com foco em colaboração com negócio |
| Unidade de Trabalho | Feature (pequena funcionalidade) | Modelo → Código | Modelo → Código | Conceitos do domínio e regras de negócio |
| Fases ou Ciclo | 2 fases: Planejamento e Construção (com 5 processos) | PIM → PSM → Código | Modelagem → Geração de código | Iterativo: modelagem colaborativa e evolução contínua |
| Colaboração com negócio | Participação do cliente com visibilidade | Limitada, foco técnico | Parcial, foco na modelagem | Forte, com uso de linguagem ubíqua e especialistas |
| Documentação | Lista de funcionalidades e modelos de classe | Modelos formais (UML) transformados em código | Modelos descritivos e documentais | Documentação dinâmica, alinhada ao modelo do domínio |
| Exemplos-chave | Cadastro de cliente, relatórios, funcionalidades visíveis | Sistema gerado via ferramenta a partir de UML | Modelagem de sistemas em BPMN/UML com geração de código | Software de gestão bancária com conceitos como Cliente, Conta |
| Ferramentas típicas | Modelagem de objetos, inspeções e builds | Ferramentas de transformação de modelos (ex: EMF, UML) | Ferramentas de modelagem + geração automática | Uso de entidades, repositórios, serviços, linguagem ubíqua |
| Benefícios | Entregas rápidas, visibilidade e rastreabilidade | Produtividade com foco em reutilização e automação | Aumento da abstração, comunicação e produtividade | Baixo acoplamento, código coeso e alinhado ao negócio |
| Desvantagens | Pouca adaptabilidade a mudanças frequentes | Alto custo inicial e dependência de ferramentas | Curva de aprendizado e dependência de ferramentas | Complexidade inicial e necessidade de forte integração |
![[PLANTÃO DE EDITAIS] 2° lote – Cabeçalho](https://blog-static.infra.grancursosonline.com.br/wp-content/uploads/2026/08/17101712/plantao-editais-lote2-cabecalho.webp)
![[PLANTÃO DE EDITAIS] 2° lote – Post](https://blog-static.infra.grancursosonline.com.br/wp-content/uploads/2026/08/17102051/plantao-editais-lote2-post.webp)


