DDD - Domain Driven Design

Uma introdução a

Domain Driven Design
Daniel Cukier
danicuki@ime.usp.br

IME-USP

quinta-feira, 26 de fevereiro de 2009

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


O que é DDD

✦ Livro de Eric Evans (2004)
✦ Padrões
✦ Boas práticas
✦ Experiência

3


Foco: Domínio

✦ Alinhamento com negócio
✦ Isolamento entre domínios
✦ Reutilização
✦ Mínimo acoplamento
✦ Independente de tecnologia

4


DDD

A volta da Orientação a Objetos?

5


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

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


Colocando o modelo
de domínio para
funcionar


Linguagem Ubíqua

9


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


Blocos de
Construção do
Model
Driven
Design

Arquitetura em Camadas
Interface
de Usuário

Aplicação

Domínio
DDD
Infra-estrutura

12


Entidades

13


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


Agregados
Interface

Entidade

Agregado
Objeto de Objeto de
Entidade
Valor Valor


Fábricas

✦ Quando construir (Agregados) for complexo
✦ Devem ser sempre abstratas
✦ Não fazem parte do modelo, mas do domínio

16


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


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


18


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


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


Refatorando
para compreender
profundamente
o modelo


Interfaces de Intenção Revelada

Eu faço
exatamente isso.
Não precisa se
preocupar como

22


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


Asserções

✦ Testes de unidade
✦ Usar facilidades da linguagem
✦ Testam o comportamento dos Comandos

24


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

Projeto Estratégico

26


Contexto Delimitado

As células existem porque sua
membrana deﬁne o que está dentro ou
fora e determina o que pode entrar

27


Integração Contínua
Testes
codiﬁcação
Novo
Elemento do
Modelo Implementação

✦ Testes automatizados
✦ Processo de build automático

✦ Sincronização diária

✦ Relatórios
28


Mapa do Contexto

Modelo no Mapa de
Contexto Modelo no
Tradução
Contexto

29


Núcleo Compartilhado

Compartilhado

Mapa de
Tradução

✦ É mais difícil fazer mudanças
✦ Evita (mas não elimina) duplicações
30


Produtor-Consumidor

✦ Testes automatizados
✦ Cliente-Fornecedor
31


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 modiﬁcação

32


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


Caminhos Separados

✦ Quando integrar custa caro e o benefício é
pequeno
✦ Contexto delimitado que não tem nenhuma
conexão com os outros

34


Resumindo

1. Trabalhando com um modelo
2. Blocos de construção
3. Refatorando e evoluindo
4. Reﬁnando, destilando

35


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


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


DDD - Domain Driven Design

Mais conteúdo relacionado

Mais procurados (20)

Destaque (12)

Semelhante a DDD - Domain Driven Design (15)

Mais de Daniel Cukier (20)

Último (19)

DDD - Domain Driven Design