Slide 1

Slide 1 text

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

Slide 103

Slide 103 text

vá em frente e divirta-se!

Slide 104

Slide 104 text

Referências

Slide 105

Slide 105 text

bit.ly/palestra-domain-driven-design

Slide 106

Slide 106 text

Avalie!

Slide 107

Slide 107 text

@marcelgsantos speakerdeck.com/marcelgsantos Obrigado. Perguntas?