1. Uma introdução a
Domain Driven Design
Daniel Cukier
danicuki@ime.usp.br
IME-USP
quinta-feira, 26 de fevereiro de 2009
2. Padrões
Um padrão é uma regra de três partes que
expressa a relação entre um certo contexto1, um
problema 2 e uma solução 3
2
quinta-feira, 26 de fevereiro de 2009
3. O que é DDD
✦ Livro de Eric Evans (2004)
✦ Padrões
✦ Boas práticas
✦ Experiência
3
quinta-feira, 26 de fevereiro de 2009
4. Foco: Domínio
✦ Alinhamento com negócio
✦ Isolamento entre domínios
✦ Reutilização
✦ Mínimo acoplamento
✦ Independente de tecnologia
4
quinta-feira, 26 de fevereiro de 2009
5. DDD
A volta da Orientação a Objetos?
5
quinta-feira, 26 de fevereiro de 2009
6. Padrões no DDD
[Contexto.]
[Discussão do problema.]
Resumo do problema.
Discussão da solução.
Por esta razão:
Resumo da solução.
Conseqüências, implementação, exemplos.
[Contexto resultante.]6
quinta-feira, 26 de fevereiro de 2009
7. DDD
Colocando o
Blocos de
modelo de
construção do
domínio para
MDD
funcionar
Refatorando
para compreender Projeto
profundamente o estratégico
modelo
7
quinta-feira, 26 de fevereiro de 2009
8. Colocando o modelo
de domínio para
funcionar
quinta-feira, 26 de fevereiro de 2009
10. Model Driven Design
Domínio
guia
Modelo Refatoração Design
Desenvolvedores
Software não serve
perdidos e tecnologia
para o domínio
inadequada
aperfeiçoa
10
quinta-feira, 26 de fevereiro de 2009
11. Blocos de
Construção do
Model
Driven
Design
quinta-feira, 26 de fevereiro de 2009
12. Arquitetura em Camadas
Interface
de Usuário
Aplicação
Domínio
DDD
Infra-estrutura
12
quinta-feira, 26 de fevereiro de 2009
13. Entidades
13
quinta-feira, 26 de fevereiro de 2009
14. Objetos de Valores
✦ Pra quem não precisa de identidade
✦ Imutáveis
✦ Descrevem coisas
✦ Ciclo de vida rápido
✦ Exemplos: Strings, números, cores
14
quinta-feira, 26 de fevereiro de 2009
15. Agregados
Interface
Entidade
Agregado
Objeto de Objeto de
Entidade
Valor Valor
quinta-feira, 26 de fevereiro de 2009
16. Fábricas
✦ Quando construir (Agregados) for complexo
✦ Devem ser sempre abstratas
✦ Não fazem parte do modelo, mas do domínio
16
quinta-feira, 26 de fevereiro de 2009
17. Serviços
1. A operação não faz parte de nenhuma
Entidade ou Objeto de Valor
2. Interface fala a língua do Domínio
3. Sem estado
17
quinta-feira, 26 de fevereiro de 2009
18. Módulos
✦ Agrupe conceitos do modelo, não código
✦ Baixo acoplamento / alta coesão
✦ Nomes da Linguagem Ubíqua
Modelo = História
Módulo = Capítulo Módulo = Capítulo
Módulo = Capítulo Módulo = Capítulo
Módulo = Capítulo Módulo = Capítulo
18
quinta-feira, 26 de fevereiro de 2009
19. Repositórios
Código
b usca
Cliente
Repositório
cria Entidade
Agregados Agregados
Agregados
Agregados
Agregados
Entidades
mo ve
Entidades
Entidades
re
Entidades
Entidades
Entidades
19
quinta-feira, 26 de fevereiro de 2009
20. Linguagem Model
Ubíqua Driven Design
exp
ress
am
ode
nomes da lo c
omo
Módulos
Serviços
Objetos Entidades acess
o com
Valor
antémde
enc m
sula integrida Repositórios
ap
comsul ncapm
e co com
m la
a
co psu
ac
ca
es
en
ocs
om
Fábricas encapsula
com Agregados
20
quinta-feira, 26 de fevereiro de 2009
21. Refatorando
para compreender
profundamente
o modelo
quinta-feira, 26 de fevereiro de 2009
22. Interfaces de Intenção Revelada
Eu faço
exatamente isso.
Não precisa se
preocupar como
22
quinta-feira, 26 de fevereiro de 2009
23. Funções sem Efeitos Colaterais
✦ Colocar tudo que for possível em funções,
principalmente em cálculos complexos
✦ Onde não der, usar Comandos que fazem
poucas operações e não retornam objetos do
domínio
23
quinta-feira, 26 de fevereiro de 2009
24. Asserções
✦ Testes de unidade
✦ Usar facilidades da linguagem
✦ Testam o comportamento dos Comandos
24
quinta-feira, 26 de fevereiro de 2009
25. Linguagem Model
Driven Design
Ubíqua
dese expressa
n
usanhadas modelo
do através de
Interfaces
de Intenção
Revelada
torna efeitos
cria seguras colaterais
e simples explícitos com
Funções
sem Efeitos Asserções
Colaterais torna
composição
segura
quinta-feira, 26 de fevereiro de 2009
27. Contexto Delimitado
As células existem porque sua
membrana define o que está dentro ou
fora e determina o que pode entrar
27
quinta-feira, 26 de fevereiro de 2009
28. Integração Contínua
Testes
codificação
Novo
Elemento do
Modelo Implementação
✦ Testes automatizados
✦ Processo de build automático
✦ Sincronização diária
✦ Relatórios
28
quinta-feira, 26 de fevereiro de 2009
29. Mapa do Contexto
Modelo no Mapa de
Contexto Modelo no
Tradução
Contexto
29
quinta-feira, 26 de fevereiro de 2009
30. Núcleo Compartilhado
Compartilhado
Mapa de
Tradução
✦ É mais difícil fazer mudanças
✦ Evita (mas não elimina) duplicações
30
quinta-feira, 26 de fevereiro de 2009
31. Produtor-Consumidor
✦ Testes automatizados
✦ Cliente-Fornecedor
31
quinta-feira, 26 de fevereiro de 2009
32. Conformista
✦ Time fornecedor não tem interesse em ajudar
✦ Tira complexidade de tradução entre contextos
✦ Mesma linguagem ubíqua
✦ Parecido com Núcleo Compartilhado, mas
cliente não tem poder de modificação
32
quinta-feira, 26 de fevereiro de 2009
33. Camada Anti-corrupção
Seu sistema Camada Anti-corrupção Outro Sistema
Classe Serviço Adaptador Interface
elegante A A complicada
Outras coisas Tradutor 1 Coisas
bem feitas irrelevantes
Fachada
Classe
Classe cara Tradutor 2 bagunçada
Ok, isso a Serviço Adaptador Você nem
gente tem que B B quer saber
refatorar
33
quinta-feira, 26 de fevereiro de 2009
34. Caminhos Separados
✦ Quando integrar custa caro e o benefício é
pequeno
✦ Contexto delimitado que não tem nenhuma
conexão com os outros
34
quinta-feira, 26 de fevereiro de 2009
35. Resumindo
1. Trabalhando com um modelo
2. Blocos de construção
3. Refatorando e evoluindo
4. Refinando, destilando
35
quinta-feira, 26 de fevereiro de 2009
37. Núcleo Serviço de
Linguagem Contexto Integração
Conformista Compar- Hospedagem
Publicada Delimitado Contínua
tilhado Aberto
Camada Interfaces de Model
Contornos Linguagem Arquitetura Mapa do
Anti- Intenção Driven
Conceituais Ubíqua em Camadas Contexto
corrupção Revelada Design
Fechamento Funções sem
Caminhos Núcleo Núcleo Objetos de
de Efeitos Entidades
Separados Abstrato Segregado Valores
Isso não é tudo
Operações Colaterais
Classes Subdomínios Núcleo do Mecanismos
Asserções Serviços Módulos
Isoladas Genéricos Domínio Coesivos
Nível de Sentença da
Ordem Núcleo
Conheci- Visão do Agregados Fábricas
que Evolui Destacado
mento Domínio
Arcabouço Camadas de
Metáfora
Componente Responsa- Repositórios
de Sistema
Plugável bilidade
quinta-feira, 26 de fevereiro de 2009
38. Referências
✦Evans, Eric - Domain Driven Design, Addison-
Wesley - 2004
✦http://www.infoq.com/resource/minibooks/
domain-driven-design-quickly/en/pdf/
DomainDrivenDesignQuicklyOnline.pdf
38
quinta-feira, 26 de fevereiro de 2009