Domain-Driven Design

Catálogo pessoal baseado no DDD Reference, de Eric Evans, resumo oficial do livro Domain-Driven Design (2003) com três padrões posteriores (Domain Event, Partnership e Big Ball of Mud). Cada padrão tem descrição, problemas que resolve, quando usar, trade-offs, etiquetas, um diagrama Mermaid e um exemplo (código ou cenário).

Padrões marcados com ★ são compartilhados com outro catálogo: este catálogo aponta para o documento original, revisado com o conteúdo desta fonte.

Total: 45 padrões em 6 grupos. Etiquetas: Objetivo de modelagem.

Putting the Model to Work (6)

Padrão	Resumo	Etiquetas
Bounded Context	Um Bounded Context define explicitamente a fronteira dentro da qual um modelo de domínio específico se aplica.	`Consistency` `Team Autonomy` `Decoupling`
Ubiquitous Language	A Ubiquitous Language é uma linguagem estruturada em torno do modelo de domínio e usada por todos os membros do time, especialistas de negócio e desenvolvedores, em todas as atividades: conversas, documentos, testes e código.	`Shared Understanding`
Continuous Integration	No DDD, Continuous Integration é o processo de integrar continuamente todo o trabalho feito dentro de um Bounded Context, para que o modelo permaneça coeso e todos os membros do time o entendam da mesma forma.	`Consistency` `Shared Understanding`
Model-Driven Design	Model-Driven Design é a ideia de que o modelo de domínio e o design do código devem estar intimamente ligados: o código é uma expressão do modelo, e uma mudança no código é uma mudança no modelo.	`Shared Understanding` `Consistency`
Hands-on Modelers	Hands-on Modelers é o princípio de que toda pessoa que contribui com o modelo deve também ter contato com o código, e toda pessoa que altera o código deve participar da conversa sobre o modelo.	`Shared Understanding` `Consistency`
Refactoring Toward Deeper Insight	Refactoring Toward Deeper Insight é a prática de refatorar o modelo e o código não apenas para limpar a implementação, mas para incorporar novo entendimento do domínio.	`Simplicity` `Strategic Focus`

Building Blocks (9)

Padrão	Resumo	Etiquetas
Layered Architecture	A Layered Architecture divide o sistema em camadas coesas, cada uma com uma responsabilidade bem definida e dependências que apontam em uma única direção.	`Decoupling` `Simplicity`
Entity	Uma Entity é um objeto do modelo definido principalmente por sua identidade, e não por seus atributos.	`Consistency` `Shared Understanding`
Value Object ★	O Value Object é um objeto pequeno e simples, como um valor monetário ou um intervalo de datas, cuja igualdade não se baseia em identidade.	`Consistency` `Simplicity` `Testability`
Domain Event ★	Um evento de domínio (Domain Event), conceito vindo do Domain-Driven Design, é um fato relevante para o negócio que ocorreu no domínio, como `PedidoCriado` ou `CreditoReservado`.	`Reliability` `Operational Excellence`
Domain Service	Um Domain Service (chamado de "Services" no livro de Evans) representa uma operação significativa do domínio que não pertence naturalmente a nenhuma entidade ou Value Object.	`Simplicity` `Shared Understanding`
Module	Um Module (pacote ou namespace) agrupa conceitos do modelo que são coesos entre si, reduzindo a carga cognitiva de quem lê o código.	`Simplicity` `Shared Understanding`
Aggregate	Um Aggregate é um grupo de entidades e Value Objects tratado como uma unidade para fins de mudança de dados.	`Consistency` `Decoupling`
Repository ★	O Repository fica entre o domínio e a camada de mapeamento de dados e apresenta os objetos persistidos por meio de uma interface semelhante à de uma coleção em memória.	`Decoupling` `Testability`
Factory	No DDD, uma Factory encapsula o conhecimento necessário para criar objetos complexos ou agregados inteiros, mantendo essa responsabilidade fora do modelo principal.	`Simplicity` `Consistency`

Supple Design (8)

Padrão	Resumo	Etiquetas
Intention-Revealing Interfaces	Intention-Revealing Interfaces consiste em nomear classes, métodos e argumentos de modo que expressem o propósito e o efeito observável, e não o modo como o resultado é obtido.	`Shared Understanding` `Simplicity`
Side-Effect-Free Functions	Side-Effect-Free Functions propõe separar as operações em duas categorias: comandos, que modificam o estado, e consultas, que apenas devolvem um resultado.	`Simplicity` `Consistency`
Assertions	Assertions consiste em declarar explicitamente as pós-condições das operações e os invariantes das classes e dos Aggregates.	`Consistency` `Shared Understanding`
Standalone Classes	Standalone Classes propõe reduzir ao mínimo as dependências de cada classe, até que ela possa ser entendida e testada sozinha, sem referenciar outras classes além de tipos primitivos e de bibliotecas básicas da linguagem.	`Decoupling` `Simplicity`
Closure of Operations	Closure of Operations consiste em definir operações cujo tipo de retorno é o mesmo tipo de seus argumentos.	`Simplicity` `Decoupling`
Declarative Design	Declarative Design é um estilo em que o comportamento do software é controlado por uma especificação executável, que descreve propriedades e regras do domínio em vez de instruções passo a passo.	`Simplicity` `Shared Understanding`
Drawing on Established Formalisms	Drawing on Established Formalisms consiste em reaproveitar, no modelo de domínio, um sistema conceitual maduro e bem compreendido, como contabilidade, álgebra, teoria dos conjuntos, lógica, cálculo de datas ou regras tributárias.	`Shared Understanding` `Consistency`
Conceptual Contours	Conceptual Contours consiste em decompor o design em unidades coesas (operações, interfaces, classes e Aggregates) alinhadas aos contornos naturais do domínio.	`Simplicity` `Strategic Focus`

Context Mapping (10)

Padrão	Resumo	Etiquetas
Context Map	O Context Map é uma visão global dos Bounded Contexts de um projeto e dos relacionamentos reais entre eles.	`Shared Understanding` `Strategic Focus`
Partnership	Partnership é um relacionamento entre dois Bounded Contexts, e entre os times que os mantêm, em que o sucesso de um depende do sucesso do outro.	`Team Autonomy` `Shared Understanding`
Shared Kernel	O Shared Kernel é um subconjunto do modelo de domínio, e do código ou do esquema de dados associado, que dois ou mais times concordam em compartilhar.	`Shared Understanding` `Consistency`
Customer/Supplier Development	No Customer/Supplier Development, dois contextos têm uma relação upstream/downstream em que o time upstream (fornecedor, supplier) atende às necessidades do time downstream (cliente, customer).	`Team Autonomy` `Shared Understanding`
Conformist	No Conformist, o time downstream decide adotar integralmente o modelo do contexto upstream, sem tradução.	`Simplicity` `Shared Understanding`
Anti-Corruption Layer ★	O Anti-Corruption Layer (camada anticorrupção) é uma fachada ou camada de adaptação colocada entre subsistemas que não compartilham a mesma semântica.	`Operational Excellence`
Open-host Service	O Open-host Service define um protocolo que dá acesso ao seu subsistema como um conjunto de serviços.	`Decoupling` `Simplicity`
Published Language	A Published Language é uma linguagem bem documentada, compartilhada e capaz de expressar o domínio necessário, usada como meio de comunicação comum entre contextos.	`Shared Understanding` `Decoupling`
Separate Ways	No Separate Ways, dois contextos decidem de forma explícita não se integrar.	`Team Autonomy` `Simplicity`
Big Ball of Mud	Big Ball of Mud é o nome, cunhado por Brian Foote e Joseph Yoder, para um sistema sem estrutura perceptível: modelos misturados, fronteiras inconsistentes, dependências em todas as direções.	`Consistency` `Strategic Focus`

Distillation (7)

Padrão	Resumo	Etiquetas
Core Domain	O Core Domain é a parte do modelo que é mais central para o sucesso do negócio: aquilo que diferencia a organização dos concorrentes e justifica a existência do software.	`Strategic Focus` `Simplicity`
Generic Subdomains	Generic Subdomains são partes do modelo que não são o diferencial do negócio e nem são específicas dele: problemas que muitas organizações compartilham, como contabilidade, controle de acesso, agendamento ou notificações.	`Strategic Focus` `Simplicity`
Domain Vision Statement	O Domain Vision Statement é um documento curto, de uma página ou menos, que descreve o Core Domain e o valor que ele entrega, sem entrar em detalhes técnicos.	`Shared Understanding` `Strategic Focus`
Highlighted Core	O Highlighted Core torna o Core Domain fácil de encontrar dentro de um modelo grande, sem alterar a estrutura do código.	`Shared Understanding` `Strategic Focus`
Cohesive Mechanisms	Cohesive Mechanisms são mecanismos computacionais complexos, como algoritmos de grafos, motores de regras ou resolução de restrições, que se infiltram no modelo de domínio e o enchem de detalhes procedimentais.	`Simplicity` `Decoupling`
Segregated Core	O Segregated Core é a reestruturação do modelo para separar fisicamente o Core Domain dos demais elementos, de modo que o core fique coeso e com poucas dependências.	`Decoupling` `Strategic Focus`
Abstract Core	O Abstract Core é um módulo separado que contém os conceitos mais fundamentais do modelo, expressos como classes abstratas e interfaces.	`Shared Understanding` `Simplicity` `Decoupling`

Large-scale Structure (5)

Padrão	Resumo	Etiquetas
Evolving Order	Evolving Order é o princípio que guia todas as estruturas de larga escala do DDD: a estrutura global de um sistema não deve ser imposta de cima para baixo no início do projeto, e sim deixada evoluir junto com a aplicação.	`Simplicity` `Strategic Focus`
System Metaphor	System Metaphor é uma estrutura de larga escala em que uma analogia concreta e fácil de entender passa a organizar o design do sistema inteiro.	`Shared Understanding` `Consistency`
Responsibility Layers	Responsibility Layers é uma estrutura de larga escala em que o domínio inteiro é organizado em poucas camadas conceituais, cada uma com uma responsabilidade ampla e bem definida.	`Decoupling` `Shared Understanding` `Consistency`
Knowledge Level	Knowledge Level é uma estrutura de larga escala que separa o modelo em dois grupos de objetos: o nível operacional, que representa as coisas do dia a dia (contas, pedidos, empréstimos), e o nível de conhecimento, um conjunto de objetos que descreve e restringe a estrutura e o comportamento do primeiro (tipos de conta, regras de produto, políticas).	`Simplicity` `Consistency`
Pluggable Component Framework	Pluggable Component Framework é uma estrutura de larga escala que surge quando um domínio maduro tem várias aplicações ou grupos de componentes que precisam interoperar.	`Decoupling` `Team Autonomy`

Por etiqueta

Grupos​

Putting the Model to Work (6)​

Building Blocks (9)​

Supple Design (8)​

Context Mapping (10)​

Distillation (7)​

Large-scale Structure (5)​

Por etiqueta​

Shared Understanding (22)​

Decoupling (13)​

Consistency (16)​

Simplicity (21)​

Team Autonomy (5)​

Strategic Focus (10)​

Testability (2)​

Reliability (1)​

Operational Excellence (2)​

Grupos

Putting the Model to Work (6)

Building Blocks (9)

Supple Design (8)

Context Mapping (10)

Distillation (7)

Large-scale Structure (5)

Por etiqueta

Shared Understanding (22)

Decoupling (13)

Consistency (16)

Simplicity (21)

Team Autonomy (5)

Strategic Focus (10)

Testability (2)

Reliability (1)

Operational Excellence (2)