35. –Melvin Conway’s Law - 1968
“Organizations which design systems are
constrained to produce designs which are
copies of the communication structures of these
organizations.”
38. –Eric Evans
“Domain-driven design
(DDD) is an approach to
developing software for
complex needs by deeply
connecting the
implementation to an evolving
model of the core business
concepts.”
46. Bounded Context
• Delimita o “Domain Model"
• Faz parte do “Solution Space”
• Funciona como um fronteira para a
Linguagem Ubíqua
• Tenta conciliar a parte técnica com a
parte de negócios
47. Bounded Context x Subdomains
• O ideal seria uma relação de 1x1.
Porém, o mundo real não é tão simples
• Um subdomain pode ser composto de
vários Bounded Contexts
• Um bounded context pode representar
vários subdomínios
51. Podem existir Bounded Contexts
não focados no negócio?
Estoque
Contabilidade
Catalogo
Compras
Pagamento
Authentication
Core
Suporte
Genérico
52. Bounded Context na prática
• Pode ser um simple diretório
• Pode ser uma App Django
• Pode ser um Microserviço
• Um software de terceiro
53. O que vai no Bounded Context?
• Entidades, Objetos de Valor,
Agregadores, Eventos, Serviços
• Tem autonomia técnica para usar
artefatos técnicos que achar melhor (Por
ex: BD)
• Fala a “Linguagem Ubíqua"
54. “O domínio muda o tempo todo.
O seu Bounded Context precisa
acompanhar essas mudanças”
55. – Vaughn Vernon -
Implementing Domain Driven
Design
“If our model were music,
they would have the
unmistakable sound of
completeness, purity, power,
and possibly event elegance
and beauty”
64. Value Objects são imutáveis!
Validação:
Ex: Final deve ser maior que Inicial
65. Entidades
• Contém estado(atributos) e comportamento(métodos)
• Local onde iremos processar a grande maioria das
nossas regras de negócio
• Devem ser “Persistent Ignorance"
66. Value Objects
• Api mais intuitiva. Nomes menores
• Organiza melhor as responsabilidades
• Pode ajudar com performance(fly-weight pattern)
• Pode ser reaproveitado
• Mais detalhes: http://bit.ly/1gL6AGL
70. Dicas para Factories
• Usado para criar objetos complexos
• Pode acessar repositórios ou serviços
• Pode ser uma Factory Class ou um Factory Method
74. Dicas para Domain Services
• Stateless
• Usado apenas quando determinada operação não se
encaixa em nenhum objeto de negócio
• Não se preocupa com transação ou qualquer outro
detalhes de infra-estrutura
• Se não for usado com cuidado, vai se transformar na
“bala de prata” para regras de negócio
• Uso excessivo vai gerar modelos anêmicos
77. Dicas para Repositórios
• Apenas uma abstração. Não sabe persistir os
dados
• Não é um DAO (Data Access Object)
• Deve parecer que está guardando tudo em
memória
• Para dados relacionais, um ORM vai tornar a vida
mais fácil
83. Dicas para Domain Events
• Dá pra implementar de várias maneiras
• Cuidado para não criar um Event Driven Design
• Só use mecanismo de fila se for muito necessário
• Não use para operações atômicas
86. Recapitulando
• Bounded Contexts, demarcam uma linguagem única
• Nossos objetos, propriedades, métodos, etc
precisam expressar linguagem ubíqua, e evitar
“corrupção" de artefatos técnicos e de outros
contextos
• Suas regras de negócio estão nas entidades
• Todos os patterns tem apenas um propósito.
Proteger o seu domínio
87. Ciclo
Failing Test Make the
test pass
Refactor
TDD
Failing Feature
Make the
Feature pass
BDD
DDD
Domain Learning
88. CORE
Entities e Value Objects
Factories, Services, Repository,
Events, ACL
Django, Flask
Nunca é 100%!!!
Arquitetura Hexagonal
93. Dicas para começar…
• Descubra quem verdadeiramente é o seu domain
expert
• Identifique os domínios e subdomínios
• Identifique os Bounded Contexts
• Comece com o Bounded Context mais fácil
tecnicamente
94. Dicas para começar…
• No inicio, o foco é aprender. Não tente fazer isso
no Core.
• Exercite o hábito de colaborar com o domain
expert.
• Trate todo o resto do software como um Big Ball of
Mud
• Exercite a Linguagem Ubíqua
95. DDD
• Colaboração!!
• Um meio de aproximar negócio e
tecnologia
• Ágil
• Mantém a ideia artesanal do
desenvolvimento de software