Workshop DDD

Domain Driven Design
Workshop
Mário Amaral
@mario_fts
github.com/mariofts
mario.amaral@caelum.com.br
Saturday, September 6, 14

Quem sou eu?
•Mário Amaral
• Instrutor e
desenvolvedor
• Caelum-Stella
• VRaptor4

Vamos começar?

Mas Primeiro...

Modelando nosso
sistema!

Funcionalidades

I - Why DDD?

Você já:
• Olhou para um código e não entendeu
o que ele fazia?
• Programou alguma funcionalidade e
não entendeu o que estava fazendo?

Problema:
Comunicação

Premissas
• “For most software projects, the
primary focus should be on the
domain and domain logic.”
• “Complex domain designs should be
based on a model.”

“Domain driven design is not a technology or a
methodology. Its a way of thinking and a set of
priorities, aimed an accelerating software projects
that have to deal with complicated domains.”

Dividir para conquistar

Camadas

User Interface
Application
Domain
Infrastructure

Domain

Comunicação

Ruído sintático
• Causado pela diferença de
representações
• Código != Linguagem escrita / falada

Ruído Semântico
• Diferença entre como o usuário pensa
em um conceito e como ele é
implementado
• Erros de comunicação e entendimento
• Necessita de constante tradução

Ruído
Sintático
Ruído
Semântico

Ruído
Sintático
Ruído
} Domain Driven
Semântico Design

Ruído
Sintático
}Domain Specific
Languages
Ruído
Semântico Saturday, September 6, 14

Como se livrar do
rúido e melhorar a
comunicação ?

Linguagem ubíqua
• Linguagem única de comunicação
• Baseada no domínio (negócio)
• Está em toda a parte
• Pode ser uma versão simplificada do
domínio real

Posso usar DDD no meu
sistema?
• Pré-requisitos
• Acesso aos especialistas de domínio
• Processo Iterativo
• Contexto definido
• Habilidade do time

Vamos modelar?

Juntando os pedaços
E aplicando a linguagem ubíqua...

II - Building Blocks

Patterns
• Entity
• Value Object
• Aggregates
• Service
• Repository
• Domain Event (Bonus Track)

Entity
• Idéia de identidade
• Mutável
• Id não necessariamente o do banco

Value Object
• Não tem identidade
• O importante é o valor que carregam
• Imutável

Aggregates
• Associações entre Entities ou Value
Objects
• Tem um objeto principal (root/raiz)
• Tratado como uma coisa só
• Sistema só deve manter referências
para a raiz do aggregate

Carro como Aggregate

Services
• Ações que não pertencem a nenhum
objeto do domínio
• Faze parte do domínio
• Stateless
• Deveriam existir poucos...

Repository
• Abstrai do domínio o acesso a dados
• Coleções de objetos, mas com
capacidade de queries avançadas
• Não necessariamente um por Entity

Domain Events
• Capturar coisas que podem disparar
uma mudança no estado do domínio
• Ótimo para integrar domínios
diferentes

III - Contexts

Será que o sistema
todo é uma coisa só?

Os cegos e o elefante
John Godfrery Saxe (1816-1887)

Bounded Context
• Fronteira bem definida entre os
diversos domínios dentro do sistema
• Delimita a aplicabilidade de um certo
modelo.

Um só contexto

Múltiplos contextos

Vários tipos de contextos
• Generic Subdomains
• Supporting Subdomain
• Core domain

Generic Context
• Existe no seu sistema, e em muitos
outros.
• Não é o foco, mas você precisa fazer.
• Ex: Contabilidade
• Pode ser comprado ou terceirizado
completamente

Supporting Context
• Específico seu
• Não é a funcionalidade principal do
seu software

Core domain
• Resolve o problema principal da
empresa
• É por essa parte que as pessoas usam
seu produto
• é suportado pelos outros contextos
• é a menor parte do sistema
(geralmente)

Outros Contextos
• Sistema legado
• Serviço remoto
• Partes do software que você não
controla
• Base legada

IV - Integrating
Contexts

Como integrar
contextos diferentes?

Sempre haverão
outros domínios
e outros modelos...

Context Maps
Transition Map

Context Maps
Transition Map
D U
U
U
D
D

Alguns patterns para
integração
• Open Host Services
• Published Language
• Anti Corruption Layer

Open Host Service
• O outro contexto é acessado por meio
de um serviço
• Pode ser um serviço dentro do seu
domínio, desde que isole o contexto

Published Languages
• Modelo “público” daquele subdomínio
• Parecido com modelo canônico (SOA)
• Pode ser um subconjunto da
linguagem daquele subdomínio

Anti Corruption Layer
• Camada de conversão
• Evita que termos estranhos entrem no
domínio
• Geralmente na ponta “D” da
integração
• Não é parte do domínio
x

V - DDD in Legacy
Systems

Big Ball of Mud

Bubble Context
• Não precisa de “muito DDD”
• Alguns dados do legado
• Isole o legado em uma bolha
• Consulte o que precisar e modifique
para seu domínio (ACL)

Autonomous Bubble
• Mais DDD
• Isole seu sistema do legado e faça a
comunicação assíncrona
• Pode ser uma evolução da bolha
• Novo contexto autônomo (novo
sistema?)

LAAS - legacy as a
service
• Pouco DDD
• Só algumas funcionalidades do legado
• Pouco acoplamento com o legado

Domain Event Channel
• Mais DDD
• Desenvolvimento independente entre
os contextos
• Comunicação entre os contextos é
feito por eventos em um canal global

Referências
• http://domainlanguage.com/newsletter/2010-09/
• http://domainlanguage.com/newsletter/2011-06/
• http://www.infoq.com/presentations/design-strategic-
eric-evans
• http://domainlanguage.com/ddd/patterns/
DDD_Reference_2011-01-31.pdf
• http://www.laputan.org/mud/
• http://www.infoq.com/author/Eric-Evans
• http://dddcommunity.org

Domain Driven Design
Workshop
Obrigado!
Mário Amaral
@mario_fts
github.com/mariofts
mario.amaral@caelum.com.br

Workshop DDD

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (16)

Similar to Workshop DDD

Similar to Workshop DDD (20)

Workshop DDD