Share
Embed
Slide 1
Slide 1 text
Então você quer ser um
praticante de DDD
@talyssonoc
Slide 2
Slide 2 text
Talysson Oliveira
Software architect
& Chief Learning Officer
na Codeminer42
@talyssonoc
beacons.ai/talyssonoc
Slide 3
Slide 3 text
2024 2025
2015
Slide 4
Slide 4 text
codeminer42.com
@codeminer42
Slide 5
Slide 5 text
Existem muitos equívocos em
torno de Domain-Driven Design
Slide 6
Slide 6 text
- DDD só adiciona complexidade desnecessária no código
- DDD é um tipo de arquitetura de software
- DDD é uma forma de organizar pastas e arquivos
- Aplicações que aplicam DDD tem arquivos demais
- Para usar DDD tem que usar um monte de design patterns
- DDD torna o código difícil de entender
- Nunca precisei usar DDD pro meu software funcionar
- …
Slide 7
Slide 7 text
Resumos, vídeos e "exemplos" que
pulam as partes importantes
😱
Slide 8
Slide 8 text
Esqueça tudo que você já ouviu
falar sobre DDD
Slide 9
Slide 9 text
Pare de achar que DDD é uma
arquitetura de software
Slide 10
Slide 10 text
Inclusive pare de associar DDD a
código por um instante
Slide 11
Slide 11 text
Para praticar DDD, você precisa
saber do que ele se trata
Slide 12
Slide 12 text
"O coração de um software é
sua habilidade de resolver
problemas relacionados ao
domínio para seus usuários"
Domain-Driven Design - Eric Evans
Slide 13
Slide 13 text
Domínio
- Finanças
- Saúde
- Educação
- Comércio
- Aviação
- Mineração
- Transporte
- …
Problema
Sistema de abstrações que
descrevem aspectos específicos do
domínio, usado para resolver
problemas relacionados ao domínio
Modelo
Slide 14
Slide 14 text
Automóveis
(Domínio) Automodelo
Slide 15
Slide 15 text
Como é cultivado o modelo?
Slide 16
Slide 16 text
Especialistas de
domínio
Especialistas de
desenvolvimento
Slide 17
Slide 17 text
Especialistas de
domínio
Especialistas de
desenvolvimento
Modelo
Slide 18
Slide 18 text
Especialistas de
domínio
Especialistas de
desenvolvimento
Modelo
Linguagem ubíqua
Slide 19
Slide 19 text
DDD é uma abordagem de
desenvolvimento onde:
- Focamos no domínio
- Exploramos modelos colaborativamente entre
especialistas de domínio e de desenvolvimento
- Falamos uma linguagem ubíqua
Slide 20
Slide 20 text
O modelo e a linguagem
ubíqua são universais?
Não
(pelo menos na maior parte dos casos)
Slide 21
Slide 21 text
Carro
Slide 22
Slide 22 text
Produto
Slide 23
Slide 23 text
Um modelo e sua linguagem ubíqua
são limitados à um contexto
Slide 24
Slide 24 text
Projetos tendem a ter
múltiplos modelos
em atividade ao mesmo tempo
Slide 25
Slide 25 text
Projetos tendem a ter
múltiplos contextos
em atividade ao mesmo tempo
Slide 26
Slide 26 text
Contexto limitado
(bounded context)
Uma divisão onde um modelo e uma
linguagem ubíqua se aplicam
Slide 27
Slide 27 text
No content
Slide 28
Slide 28 text
No content
Slide 29
Slide 29 text
Mapeamento de contextos
- Definição dos pontos de contato entre modelos, delimitando mecanismos de
compartilhamento, isolamento e influência entre eles
- Descoberta das relações entre os contextos que impõe restrições na
natureza do modelo ou no ritmo viável para mudanças
- Contextos que se dependem mutuamente
- Contextos que suportam múltiplos outros contextos
- Contextos que dependem unilateralmente de outros
- Contextos que nunca precisam interagir entre si
- Muitas vezes a natureza dessa relação pode ser inclusive não-técnica
- Ex.: serviço terceirizado de processamento de pagamentos
Slide 30
Slide 30 text
No content
Slide 31
Slide 31 text
Design
estratégico
Slide 32
Slide 32 text
Fonte:
Slide 33
Slide 33 text
Por favor, não achem que DDD é o só o
que falaremos daqui pra frente
⚠
Slide 34
Slide 34 text
Vamos falar de código
Slide 35
Slide 35 text
Modelo
Sistema de abstrações que descrevem
aspectos específicos do domínio, usado para
resolver problemas relacionados ao domínio
Slide 36
Slide 36 text
Model-Driven Design
Slide 37
Slide 37 text
id
status
shippingAddress
estimatedDelivery
Pedido
Slide 38
Slide 38 text
id: 42
status: pending
shippingAddress: Rua ABC
estimatedDelivery: 10/10/2025
Pedido #42
t
Slide 39
Slide 39 text
id: 42
status: pending
shippingAddress: Rua ABC
estimatedDelivery: 10/10/2025
id: 42
status: pending
shippingAddress: Av. XYZ
estimatedDelivery: 10/10/2025
Pedido #42
t
Slide 40
Slide 40 text
id: 42
status: pending
shippingAddress: Rua ABC
estimatedDelivery: 10/10/2025
id: 42
status: shipped
shippingAddress: Av. XYZ
estimatedDelivery: 11/11/2025
Pedido #42
t
id: 42
status: pending
shippingAddress: Av. XYZ
estimatedDelivery: 10/10/2025
Slide 41
Slide 41 text
id: 42
status: pending
shippingAddress: Rua ABC
estimatedDelivery: 10/10/2025
id: 42
status: shipped
shippingAddress: Av. XYZ
estimatedDelivery: 11/11/2025
Pedido #42
t
id: 42
status: pending
shippingAddress: Av. XYZ
estimatedDelivery: 10/10/2025
Identidade + ciclo de continuidade = Entidade (entity)
Slide 42
Slide 42 text
No content
Slide 43
Slide 43 text
red
green
blue
Cor
Slide 44
Slide 44 text
red: 255
green: 0
blue: 0
Vermelho
Slide 45
Slide 45 text
red: 255
green: 0
blue: 0
Vermelho
red: 255
green: 0
blue: 255
Rosa
Slide 46
Slide 46 text
red: 255
green: 0
blue: 0
Vermelho
red: 255
green: 0
blue: 255
Rosa
red: 110
green: 200
blue: 80
Verde
Slide 47
Slide 47 text
red: 255
green: 0
blue: 0
Vermelho
red: 255
green: 0
blue: 255
Rosa
red: 110
green: 200
blue: 80
Verde
Ausência de identidade +
significado proveniente
dos valores dos atributos
= Objeto de valor
(value object)
Slide 48
Slide 48 text
No content
Slide 49
Slide 49 text
id
status
shippingAddress
estimatedDelivery
Pedido
color
carId
tires
Personalizações
airConditioner
mediaPlayer
Extras
paymentMethod
totalPrice
Pagamento
Slide 50
Slide 50 text
id
status
shippingAddress
estimatedDelivery
Pedido
color
carId
tires
Personalizações
airConditioner
mediaPlayer
Extras
paymentMethod
totalPrice
Pagamento
Slide 51
Slide 51 text
id
status
shippingAddress
estimatedDelivery
Pedido
color
carId
tires
Personalizações
airConditioner
mediaPlayer
Extras
paymentMethod
totalPrice
Pagamento
Slide 52
Slide 52 text
id
status
shippingAddress
estimatedDelivery
Pedido
color
carId
tires
Personalizações
airConditioner
mediaPlayer
Extras
paymentMethod
totalPrice
Pagamento
Entidade principal + fronteira de
consistência conceitual
= Agregado
(aggregate)
Raiz do agregado
(aggregate root)
Slide 53
Slide 53 text
No content
Slide 54
Slide 54 text
buscar pedido por id
buscar pedidos por status
persistir um pedido
Pedido
(agregado)
Slide 55
Slide 55 text
buscar pedido por id
buscar pedidos por status
Ações de interesse do
domínio
persistir um pedido
Pedido
(agregado)
Slide 56
Slide 56 text
buscar pedido por id
buscar pedidos por status
Ações de interesse do
domínio
Agregados que requerem
acesso direto + conjunto de
ações de persistência de
interesse do domínio
= Repositório (repository)
persistir um pedido
Pedido
(agregado)
Slide 57
Slide 57 text
= Repositório (repository)
OrderRepository
+ findById(id)
+ findAllByStatus(status)
+ store(pedido)
Agregados que requerem
acesso direto + conjunto de
ações de persistência de
interesse do domínio
Slide 58
Slide 58 text
No content
Slide 59
Slide 59 text
Design
estratégico
Slide 60
Slide 60 text
Design
estratégico
Design tático
Slide 61
Slide 61 text
Combine design estratégico com design tático!
Fuja do suposto "DDD lite"
Slide 62
Slide 62 text
Quais os próximos passos?
Slide 63
Slide 63 text
Próximos passos
1. Certifique-se que entendeu que DDD não é primariamente sobre código
2. Não busque atalhos, fuja do suposto "DDD lite"
3. Leia o minibook DDD Quickly
4. Assista a talk "7 Reasons Why DDD Projects Fail", Greg Young
5. Aprenda a base de maneira sólida, não faça isso com pressa
- Domain-Driven Design, Eric Evans (the blue book) ou Learning Domain-Driven Design, Vlad Khononov
6. Pratique!
7. Aprofunde os conhecimentos
- Implementing Domain-Driven Design, Vaughn Vernon (the red book)
8. Pratique, não busque atalhos, e fuja do suposto "DDD lite"!
Slide 64
Slide 64 text
Obrigado!
@talyssonoc
beacons.ai/talyssonoc
@codeminer42
codeminer42.com