Este documento discute os principais conceitos do Domain-Driven Design (DDD), incluindo:
1) DDD é focado na redução da complexidade de software através da compreensão do domínio do negócio e da criação de modelos expressivos.
2) Os subdomínios são decompostos e os contextos delimitados mapeiam como cada parte será implementada tecnicamente.
3) Os modelos de domínio representam a lógica e regras de negócio de cada subdomínio.
6. Big Ball Of Mud – Grande Bola de Lama
• A arquitetura não é bem definida
• Correções e pequenas evoluções
tornam-se um grande desafio devido a
dificuldade de entender o código
• Evans: “BBoM é aquele código faz
alguma coisa útil, mas sem explicar
como”
7. “DDD é sobre a redução de complexidade
no software”
Eric Evans
9. Domínio do Negócio (Domain)
• Uma esfera de conhecimento
• O que ela faz e como ela faz...
• Cada empresa
• tem o know-how do segmento/problema que ela atende
• E o seu jeito de fazer
• Conhecer o domínio é a parte mais importante do DDD
10. Exemplo de Domínio
• Se você estiver criando um software para gerenciar avaliações de
desempenho dos funcionários, você precisará compreender
• como as avaliações realmente funcionam,
• todo o fluxo de trabalho,
• as necessidades e expectativas dos clientes,
• como isso afeta a folha de pagamento, etc.,
11. DDD é sobre criar modelos altamente
expressivos
12. O que é um Modelo?
• Simplificação da realidade
• Mostra alguns aspectos da realidade
ou uma ideia de interesse
19. Logo...
• Domain expert acessível;
• Alta interação entre o domain expert e o time de desenvolvimento;
Manifesto Ágil
• Indivíduos e interações mais que processos e ferramentas
• Colaboração com o cliente mais que negociação de contratos
• Princípio: Pessoas relacionadas à negócios e desenvolvedores devem
trabalhar em conjunto e diariamente, durante todo o curso do
projeto.
http://www.manifestoagil.com.br
24. • Antes de colocar a mão na massa e falar sobre
codificação, você deve entender o Problema
• O DDD enfatiza
• Suas terminologias (LU)
• A razão pela qual está sendo desenvolvido
• Quais são os fatores de sucesso para o negócio
• A necessidade de a equipe de desenvolvimento
valorizar o conhecimento do domínio, tanto quanto
a experiência técnica
26. Problema
Domínio
VendoLivros S/A
Loja de Livros A VendoLivros S/A é uma empresa
que comercializa apenas livros, seu
grande diferencial está na entrega,
que é bem mais rápida que seus
concorrentes devido a sua grande
expertise em logística e
distribuição.
28. Lei de Conway
Presidência
Vendas
..
Marketing
..
Pagamentos Estoque Entrega ...
Resumo: A forma como as organizações estão estruturadas
tem um forte impacto sobre os sistemas que elas criam
"Qualquer empresa que projeta um sistema (definição mais ampla
aqui do que apenas sistemas de informação), inevitavelmente produz
um projeto cuja estrutura é uma cópia da estrutura de comunicação
da organização.“ Melvin Conway (1968)
29. Decompondo o problema Subdomínio
Estoque
RH, Financeiro
Tesouraria
...
Vendas
Marketing
Entrega
Domínio
VendoLivros
Catálogo
Pedidos
Preços
Localização
Armazenamento
Taxa de entrega
Prazo de entrega
Parceiros de transporte
Propaganda
Promoções
Pagamentos
Boleto
Cartão de Crédito
Presidên
cia
ndas
..
Marketi
ng
..
Pagame
ntos
Estoque Entrega ...
30. Decompondo o problema Subdomínio
Estoque
RH, Financeiro
Tesouraria
...
Vendas
Marketing
Entrega
Pagamentos
Domínio Principal (Core Domain)
• Sucesso para o negócio
• Focar todos os esforços
31. Decompondo o problema Subdomínio
Estoque
RH, Financeiro
Tesouraria
...
Vendas
Marketing
Entrega
Pagamentos
Domínio Principal (Core Domain)
• Sucesso para o negócio
• Focar todos os esforços
Subdomínio de Suporte
• Essenciais mas não o core
• Desenvolver ou comprar
32. Decompondo o problema Subdomínio
Estoque
RH, Financeiro
Tesouraria
...
Vendas
Marketing
Entrega
Pagamentos
Domínio Principal (Core Domain)
• Sucesso para o negócio
• Focar todos os esforços
Subdomínio de Suporte
• Essenciais mas não o core
• Desenvolver ou comprar
Subdomínio Genérico
• Não agrega valor para o negócio
• Se possível, Comprar / Github
34. Foco no Domínio Principal
Não perca tempo e esforço para refatorar todo o seu código, foque no
domínio principal!
Para subdomínios de suporte e genéricos, o código bom é o suficiente.
A perfeição é uma ilusão, e deve ser reservada apenas para o que é
essencial
O negócio não se preocupa com a qualidade do código
para as áreas que não são essenciais
Scott Millett
35. Decompondo o problema Modelo de Domínio (Domain Model)
Estoque
RH, Financeiro
Tesouraria
...
Vendas
Marketing
Entrega
Pagamentos
Representa a lógica de domínio e as
regras de negócios que são relevantes
para o subdomínio
Modelo de
Domínio
Modelo de
Domínio
Modelo de
Domínio
Modelo de
Domínio
Modelo de
Domínio
Modelo de
Domínio
Livro
38. Contextos Delimitados (Bounded Context)
• Definem a maneira como um subdomínio será resolvido
tecnicamente pela solução
• Enquanto o conceito do Subdomínio pertence ao que chamamos de
Espaço Problema, os Contextos Delimitados pertencem ao Espaço
Solução
40. Contextos Delimitados (Bounded Context)
Contexto de
Catálogo
Contexto de
Precificação
Contexto de
Pedidos
Subdomínio de Vendas
Contexto de
Promoções
Contexto de
Publicidade
Subdomínio de
Marketing Contexto de
Estoque
Subdomínio de
Estoque
Contexto de
Pagamento
Subdomínio de
Pagamento
Contexto de
Entrega
Subdomínio de
Entrega
Contexto de
ERP Legado
Subdomínio de
ERP Legado
41. Contextos Delimitados (Bounded Context)
Contexto de
Catálogo
Contexto de
Precificação
Contexto de
Pedidos
Subdomínio de Vendas
Contexto de
Promoções
Contexto de
Publicidade
Subdomínio de
Marketing Contexto de
Estoque
Subdomínio de
Estoque
Contexto de
Pagamento
Subdomínio de
Pagamento
Contexto de
Entrega
Subdomínio de
Entrega
Contexto de
ERP Legado
Subdomínio de
ERP Legado
Sistema VendoLivros Online
43. Contextos Delimitados (Bounded Context)
Contexto de
Catálogo
Contexto de
Precificação
Contexto de
Pedidos
Subdomínio de Vendas
Contexto de
Promoções
Contexto de
Publicidade
Subdomínio de
Marketing Contexto de
Estoque
Subdomínio de
Estoque
Contexto de
Pagamento
Subdomínio de
Pagamento
Contexto de
Entrega
Subdomínio de
Entrega
Contexto de
ERP Legado
Subdomínio de
ERP Legado
• Tornar o Implícito Explicito
• Define explicitamente o
contexto dentro do qual
um modelo se aplica.
• É delimitado pela
linguagem compartilhada
• Protege seu modelo
Livro
Livro
Livro
Livro
Livro
Livro
Livro
46. Mapa de Contexto
• Estabelece uma visão da comunicação entre as equipes
• Torna as delimitações dos contextos explícitos
• Fornece a visão para possíveis alterações e evoluções
• Estabelece um conjunto de padrões de comunicações
• Núcleo compartilhado
• Cliente Fornecedor
• Conformista
• Parceria
• Camada de Anticorrupção
• Linguagem Publicada
48. Núcleo Compartilhado (Shared Kernel)
• Dois times compartilham um subconjunto de modelo de um mesmo subdomínio
• Alterações dentro do núcleo compartilhado devem ser acordadas entre as duas
equipes
• Integração Contínua
• Geralmente é o Domínio Principal
Contexto de
Folha de Pagamento
Contexto de
Recursos Humanos
Modelo de Domínio
Do Funcionário
Subdomínio
Recurso Humanos
49. Baseado em direções
• O Downstream é o lado do relacionamento que depende de dados ou
comportamentos do lado Upstream
Contexto
Downstream
Contexto
Upstream
50. Cliente/Fornecedor (Customer/Supplier)
• É uma relação de cliente e fornecedor
• Orçar/Estimar
• Planejamento da entrega
• Direito a veto, negociar com o Fornecedor
• Interação – O team Cliente deve estar disponível para sanar dúvidas
Contexto Vendas Contexto
Pedidos
Customer-Supplier
Downstream Upstream
Consome/utiliza de
51. Cliente/Fornecedor (Customer/Supplier)
• Testes automatizados
• Escritos pela equipe de cliente (definindo a interface esperada)
• Executados pela equipe Fornecedor (Para garantir que não estão quebrando
nada)
Contexto Vendas Contexto
Pedidos
Customer-Supplier
Downstream Upstream
Consome/utiliza de
52. Cliente/Fornecedor (Customer/Supplier)
• Equipes de Clientes/Fornecedores tem maior chance de sucesso se
elas trabalham sob a mesma gerência e compartilham os mesmos
objetivos
Contexto Vendas Contexto
Pedidos
Customer-Supplier
Downstream Upstream
Consome/utiliza de
53. Conformista (Conformist)
• Não há colaboração entre o contexto downstream e o upstream
• Muito comum em relacionamento com contextos que representam
um sistema de terceiro, API...
A A
Contexto Vendas Contexto
Pagamentos
Conformista
Downstream Upstream
Consome/utiliza de
54. Conformista (Conformist)
• Se o Upstream é uma bagunça, essa bagunça será propagada para o
Downstream
• É caro criar uma camada de tradução para que os objetos do
upstream não corrompem o modelo do downstream
A A
Contexto Vendas Contexto
Pagamentos
Conformista
Downstream Upstream
Consome/utiliza de
55. Camada de Anticorrupção (Anti-Corruption Layer)
• Criar uma camada para tradução entre os termos do Upstream para o
modelo do Downstream, e vice-e-versa.
• Protege o modelo de domínio de influências externas
Contexto Vendas Contexto
Pagamentos
ACL
Anti-Corruption
Layer
Downstream Upstream
57. Parceria (Partnership)
• Dependência mútua entre os contextos/equipes, elas obtém o sucesso ou
fracasso juntas;
• Possuem um objetivo em comum
• Cooperam na evolução das interfaces para acomodar as necessidades de ambos
• Entregas/Releases são alinhadas
Contexto Vendas Contexto Pedidos
Partnership
58. Caminhos separados (Separate Ways)
• Quando realmente não há relacionamento entre os contextos
• Quando o custo de tradução é tão grande que é preferível a duplicação de parte
do modelo e que eles sigam em Caminhos separados.
Contexto Publicidade Contexto Entrega
59. Linguagem Publicada (Published Language)
• Quando você quer abrir seu contexto para integração com vários clientes
• Se muitos contextos compartilham a mesma lógica de tradução, pode ser
preferível que se tenha uma forma de acesso com interfaces claramente
definidos
• Define o protocolo de comunicação
Serviço Aberto de Funcionalidades
(Open/Host Service)
• Quando você quer definir uma linguagem comum para comunicação
60. Comunicação através de API REST, JSON/XML
Contexto Pedido
Contexto Estoque
Contexto Entrega
Contexto Catálogo
OHS
61. A estratégia sem tática é o caminho mais lento para a vitória.
Sun Tzu
Arte da Guerra
68. Objeto de Valor (Value Object)
Imutável
Não tem uma identidade
A sua igualdade é dada pelas
suas propriedades
Tem Regra de negócio
69. Objeto de Valor (Value Object)
• Reduz o code smell “Obsessão com tipos Primitivos”
70. Agregado Raiz
Entidade
Objeto Valor
Agregados (Aggregate)
• Compostos de Entidades
ou Objetos de Valores
que são encapsulados
numa única classe;
• Serve para manter a
integridade do modelo;
• Possui uma raiz de
agregação (Aggregate Root);
• Único repositório por
raiz de agregação;
71. Serviço de Domínio (Domain Service)
• Classes que contém uma lógica de negócio mas que não pertencem a
nenhuma entidade ou objeto de valor;
• Serviços não guardam estado (Stateless);
• Toda chamada a um mesmo serviço, com a mesma pré-condição deve retornar o mesmo
resultado.
• Orquestrar entidades e encapsular regras de negócios;
• Conceito de domínio que vem da LU e que envolve várias entidades;
• Protege o modelo (entidade / objeto de valor)
72. Evento de Domínio (Domain Event)
• Notifica aos interessados que algo importante aconteceu no domínio;
• Exemplo de eventos:
• Livro entregue
• Livro foi separado
• Livro foi enviado
• Pedido gerado
• OCP – Aberto para extensão e fechado para alteração
73. Critérios Técnicos
Por Conceitos da LU
Módulo (Module)
• Divide o código por conceito (LU) e não por
critério técnico;
• São usados para decompor o modelo de domínio;
• Permitem ao desenvolvedor ler e entender
rapidamente o modelo do domínio;
• Namespace / Projects
74. Fábrica (Factory)
• Utilize construtores apenas para criação de objetos simples,
• Para objetos complexos utilize fábricas
• Encapsula toda a lógica necessária para criar um Agregado em um
estado consistente
• Centraliza a lógica de criação
• Utilize os padrões GoF:
• Factory Method
• Abstract Factory
• Builder
75. Repositório (Repository)
• É o mecanismo que você deve usar para recuperar e persistir
agregados
• Persistência Agnóstica, é uma preocupação de infraestrutura, não do
modelo
• Pode ser útil se apoiar em estruturas de ORM (Entity Framework,
NHibernate)
• Um por Raiz de Agregação
• Não é indicado para Relatórios e telas de consultas complexas
76. Especificação (Specification)
• Torna a regra de negócio implícita explicita
• Utilizado principalmente para validações
• Permite a criação de especificações compostas (utilizando E, OU, Não)
77. Quando NÃO utilizar DDD
Quando...
• o domínio não é complexo, pode ser resolvido com um simples CRUD
• a solução é muito mais técnica do que de negócio, Ex: Um framework
• o Domain Expert não é acessível
• você não tem um time motivado e qualificado
• o processo de desenvolvimento é cascata
78. Adotar DDD só porque é legal
Ignorar o DDD porque o domínio parece ser pouco complexo
79. E se você não seguir o DDD em aplicações
complexas...?
• Provavelmente você terá um modelo anêmico com muitos serviços
• Regras de negócios ficam espalhadas em classes que não são do
domínio
• Difícil de mudar o sistema em uma alteração/evolução da regra de
negócio
• Comunicação negligenciada
87. Conteúdo do Curso
• Introdução
• Linguagem Obíquoa
• Domínios Ricos vs Domínios
Anêmicos
• Sub Domínios
• Separação em Contextos
Delimitados
• Organizando a Solução
• Definindo as Entidades
• Corrupção no Código
• SOLID e Clean Code
• Primitive Obsession
• Value Objects
• Compartilhando Informações
entre Contextos Delimitados
• Testando as Entidades e VOs
• Commands
• Fail Fast Validations
• Testando os Commands
• Repository Pattern
• Handlers
• Testando os Handlers
• Queries
• Testando suas Queries
http://live.balta.io/