Marcel Gonçalves dos Santos
@marcelgsantos
domain-driven design
introdução a
Slide 2
Slide 2 text
pensandonaweb.com.br
desenvolvedor web full-stack
Marcel Gonçalves dos Santos
@marcelgsantos
Slide 3
Slide 3 text
@phpsp
phpsp.org.br
Slide 4
Slide 4 text
Interaja nas mídias sociais!
- fale sobre o evento, palestrantes e conteúdo
- tire fotos do evento e publique
- interaja com outros participantes do evento
- tire dúvidas ou dê feedbacks para os palestrantes
Slide 5
Slide 5 text
O que é
domain-driven design?
Slide 6
Slide 6 text
o domain-driven design é uma
abordagem para o desenvolvimento
de softwares complexos
Slide 7
Slide 7 text
o termo é o nome de um livro famoso
conhecido como "livro azul" escrito
por Eric Evans em 2003
Slide 8
Slide 8 text
No content
Slide 9
Slide 9 text
"Domain-Driven Design: Tackling
Complexity in the Heart of Software"
Slide 10
Slide 10 text
e, como diz o título do livro, domain-driven
design é sobre atacar as complexidades
no coração do software
Slide 11
Slide 11 text
o domínio é o coração do software e onde
estão as regras de negócio
Slide 12
Slide 12 text
"The heart of software is its ability to solve
domain-related problems for its user."
― Eric Evans, Domain-Driven Design
Slide 13
Slide 13 text
o domínio possui uma complexidade
intrínseca, isto é, a complexidade do
problema a ser resolvido
Slide 14
Slide 14 text
e, segundo Evans, devemos nos interessar
mais pela complexidade do domínio
Slide 15
Slide 15 text
Complexidade acidental
e complexidade essencial
Slide 16
Slide 16 text
a complexidade acidental é aquela que é
decorrente da solução adotada
Slide 17
Slide 17 text
exemplo 01
escolher entre utilizar monolitos ou
microsserviços, framework A ou B, banco de
dados relacionais ou não-relacionais são
exemplos de complexidades acidentais
Slide 18
Slide 18 text
a complexidade essencial é aquela que é
inerente ao problema a ser resolvido
Slide 19
Slide 19 text
exemplo 02
a coordenação de motoristas de aplicativos,
isto é, identificar os motoristas disponíveis
nas imediações da solicitação de uma
chamada é um exemplo de complexidade
essencial pois faz parte do problema
Slide 20
Slide 20 text
a complexidade essencial é aquela que
não pode ser evitada e está relacionada
a complexidade do domínio
Slide 21
Slide 21 text
para entender melhor o domínio devemos
conversar com os especialistas de domínio
Slide 22
Slide 22 text
Linguagem Ubíqua ou
Linguagem Onipresente
Slide 23
Slide 23 text
a linguagem ubíqua ou linguagem
onipresente é uma linguagem comum
utilizada para expressar o domínio
Slide 24
Slide 24 text
a linguagem ubíqua é a linguagem criada
pelo time de desenvolvimento em conjunto
com os especialistas de domínio
Slide 25
Slide 25 text
ela deve expressar o negócio na
comunicação falada, em documentos
e na forma de código
Slide 26
Slide 26 text
ela surge da conversa com especialistas
de domínio e deve ser compreendida
por todos e sem ambiguidade
Slide 27
Slide 27 text
o código desenvolvido deverá utilizar a
linguagem ubíqua no nome de módulos,
classes, métodos e funções
Slide 28
Slide 28 text
a linguagem ubíqua existe dentro de um
contexto específico, isto é, um contexto
delimitado
Slide 29
Slide 29 text
exemplo 03
um especialista de domínio descreve o
seguinte cenário: "o cliente poderá finalizar o
pedido quando estiver satisfeito com os
itens em seu carrinho de compras"
Slide 30
Slide 30 text
no código teremos:
- uma classe para a entidade Cliente
- uma classe para a entidade
CarrinhoDeCompras
- um método para a ação finalizarPedido()
Slide 31
Slide 31 text
"To communicate effectively, the code must
be based on the same language used to
write the requirements—the same language
that the developers speak with each other
and with domain experts."
― Eric Evans, Domain-Driven Design
Slide 32
Slide 32 text
Big Ball of Mud
Slide 33
Slide 33 text
uma "big ball of mud" ou grande bola de
lama é um código com uma arquitetura mal
definida…
Slide 34
Slide 34 text
…e que correções e pequenas evoluções se
tornam um grande desafio pela dificuldade
de compreender o código
Slide 35
Slide 35 text
No content
Slide 36
Slide 36 text
"A big ball of mud is haphazardly
structured, sprawling, sloppy, duct-tape
and bailing wire, spaghetti code jungle.”
― Brian Foote and Joseph Yoder, 1999
Slide 37
Slide 37 text
"Uma grande bola de lama é uma selva de
código espaguete, aleatoriamente
estruturado, espalhado, desleixado e cheio
de fita adesiva."
― Brian Foote and Joseph Yoder, 1999
Slide 38
Slide 38 text
Subdomínios
Slide 39
Slide 39 text
um domínio costuma ter separações que
são chamadas subdomínios
Slide 40
Slide 40 text
os tipos de subdomínios são: subdomínio
principal, subdomínio de suporte e
subdomínio genérico
Slide 41
Slide 41 text
subdomínio principal
- domínio que traz valor para o negócio e
onde fica a lógica principal
- é a atividade principal da empresa e
geralmente é um software feito sob medida
Slide 42
Slide 42 text
subdomínio de suporte
- suporta o domínio principal
- é importante mas não representa o
negócio principal
Slide 43
Slide 43 text
subdomínio genérico
- não possui relação direta com o domínio
principal
- geralmente faz uso de software terceiro
Slide 44
Slide 44 text
No content
Slide 45
Slide 45 text
Contextos Delimitados
ou Bounded Contexts
Slide 46
Slide 46 text
contexto delimitado ou bounded context é
uma fronteira conceitual onde reside o
modelo de domínio e a linguagem ubíqua
Slide 47
Slide 47 text
os contextos delimitados buscam delimitar
o seu domínio complexo em contextos
baseados nas intenções do negócio
Slide 48
Slide 48 text
a linguagem ubíqua dentro de um contexto
permite definir o limite de conceitos que
podem ser diferentes dentro de diferentes
contextos
Slide 49
Slide 49 text
exemplo 04
uma entidade Usuario no contexto A pode
ser diferente de uma mesma entidade
Usuario no contexto B
Slide 50
Slide 50 text
cada contexto delimitado possui a sua
própria linguagem ubíqua
Slide 51
Slide 51 text
isto significa que você deve delimitar as
intenções de suas entidades com base no
contexto que ela pertence
Slide 52
Slide 52 text
cada contexto delimitado pode ter a sua
própria arquitetura, modelo de persistência
e ser desenvolvido por um time diferente
Slide 53
Slide 53 text
um contexto delimitado é um reflexo da
estrutura organizacional que se possui na
empresa
Slide 54
Slide 54 text
os contextos delimitados podem se
comunicar de diversas maneiras como, por
exemplo, utilizando APIs REST ou sistema
de mensageria
Slide 55
Slide 55 text
um subdomínio é relacionado ao problema
de domínio e o bounded context é
relacionado à solução do problema
Slide 56
Slide 56 text
"Se os limites dos nossos serviços alinham-
se aos contextos delimitados do nosso
domínio, nós começamos bem para
garantir que nossos microsserviços estão
com baixo acoplamento e alta coesão"
― Sam Newman
Slide 57
Slide 57 text
Mapas de Contextos
ou Context Maps
Slide 58
Slide 58 text
o mapa de contextos permite documentar
os contextos delimitados e desenhar o
relacionamento entre eles
Slide 59
Slide 59 text
o mapa de contextos é uma ferramenta
estratégica que mostra a relação entre os
subdomínios
Slide 60
Slide 60 text
No content
Slide 61
Slide 61 text
os padrões de compartilhamento são:
- núcleo compartilhado
- produtor-consumidor
- conformista
- parceria
- camada anticorrupção
Slide 62
Slide 62 text
Design Tático e
Design Estratégico
Slide 63
Slide 63 text
o domain-driven design fornece um
conjunto de conceitos e padrões para
auxiliar no projeto do software em nível
tático e estratégico
Slide 64
Slide 64 text
o design tático refere-se a implementação
de código
Slide 65
Slide 65 text
é no design tático que falamos sobre
entidades, objetos de valor, serviços de
domínio, eventos de domínio, agregados,
repositórios e fábricas
Slide 66
Slide 66 text
os padrões não são exclusividade do
domain-driven design, isto é, eles já eram
conhecidos e utilizados anteriormente
Slide 67
Slide 67 text
o design estratégico refere-se ao
relacionamento e comunicação entre os
subdomínios
Slide 68
Slide 68 text
"Design estratégico é como fazer o rascunho antes
de entrar nos detalhes da implementação. Destaca
o que é estrategicamente importante para o seu
negócio, como dividir o trabalho por importância e
como fazer integrações da melhor maneira."
― Vaughn Vernon
Slide 69
Slide 69 text
Arquitetura em
Camadas
Slide 70
Slide 70 text
a arquitetura em camadas é utilizada para
organizar a aplicação e permite separá-la em
camadas com responsabilidades específicas
Slide 71
Slide 71 text
No content
Slide 72
Slide 72 text
interface de usuário
responsável por exibir informações e
interpretar comandos do usuário
Slide 73
Slide 73 text
aplicação
responsável por conectar a camada de
interface de usuário com as outras
camadas
Slide 74
Slide 74 text
domínio
responsável por conter os conceitos e regras
de negócio relacionados ao domínio e é o
principal foco do domain-driven design
Slide 75
Slide 75 text
infraestrutura
responsável por fornecer os recursos
técnicos que dão suporte às outras camadas
como persistência de dados e I/O
Slide 76
Slide 76 text
"Isolating the domain implementation is a
prerequisite for domain-driven design."
― Eric Evans
Slide 77
Slide 77 text
Blocos de Construção
ou Building Blocks
Slide 78
Slide 78 text
entidades
são objetos que possuem uma identidade
Slide 79
Slide 79 text
objetos de valor
são objetos que carregam valor, não
possuem identidade e são imutáveis
Slide 80
Slide 80 text
No content
Slide 81
Slide 81 text
agregados
um agregado é, de forma simples, um
conjunto entidades e objetos de valor
Slide 82
Slide 82 text
agregados
é um elemento conceitual que é responsável
por conter outras entidades que não podem
ser acessadas de fora
Slide 83
Slide 83 text
agregados
para isso utiliza-se o encapsulamento e a lei
de Demeter e sempre falaremos com o
aggregate root
Slide 84
Slide 84 text
No content
Slide 85
Slide 85 text
eventos de domínio
representa algo que ocorreu no domínio e
que é desejado que outras partes tenham
conhecimento
Slide 86
Slide 86 text
eventos de domínio
permite expressar de forma explícita um
efeito colateral
Slide 87
Slide 87 text
No content
Slide 88
Slide 88 text
fábricas
classes responsáveis pela criação de
agregados ou objetos de valor
Slide 89
Slide 89 text
fábricas
agregados são complexos e as fábricas
permitem extrair a complexidade de criação
de uma agregado de sua definição
Slide 90
Slide 90 text
serviços
classes que contém regra de negócio mas
que não pertencem a nenhuma entidade ou
objeto de valor
Slide 91
Slide 91 text
repositórios
um repositório é responsável por acessar
uma camada de dados externa
Slide 92
Slide 92 text
repositórios
o domínio não deve estar acoplado a um
banco de dados e, para isso, utiliza-se
abstrações (e, mais especificamente, o
padrão data mapper)
Slide 93
Slide 93 text
módulos
abstrações que têm por objetivo agrupar
classes por um determinado conceito do
domínio
Slide 94
Slide 94 text
módulos
pode-se utilizar pacotes em Java,
namespaces em PHP ou módulos em
JavaScript
Slide 95
Slide 95 text
módulos
o agrupamento não deve ser feito segundo
conceitos de infraestrutura e, sim, conceitos
de domínio
Slide 96
Slide 96 text
No content
Slide 97
Slide 97 text
Conclusão
Slide 98
Slide 98 text
o foco do domain-driven design é atender
as necessidades do domínio, ou seja, a
complexidade essencial
Slide 99
Slide 99 text
para isso, deve-se utilizar a linguagem
onipresente para aproximar os especialistas
de domínio da equipe técnica
Slide 100
Slide 100 text
"DDD é primariamente sobre modelar uma
linguagem ubíqua em contexto delimitado"
― Vaughn Vernon
Slide 101
Slide 101 text
domain-driven design não é sobre
arquitetura e, sim, sobre priorizar o domínio
Slide 102
Slide 102 text
uma aplicação construída com domain-
driven design pode fazer uso de qualquer
decisão arquitetural como arquitetura
hexagonal, CQRS ou clean architecture