Começando a modelar sua aplicação Ruby com DDD

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Desenvolvendo software no dia-a-dia

Slide 3

Slide 3 text

Mundo Real Software

Slide 4

Slide 4 text

"The real world does not ﬁt in the softwares" (Vaughn Vernon)

Slide 5

Slide 5 text

Nas primeiras tentativas de mapear essa realidade...

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

No content

Slide 8

Slide 8 text

Funciona !!!

Slide 9

Slide 9 text

#sqn

Slide 10

Slide 10 text

O problema / expectativa

Slide 11

Slide 11 text

Alinhamento de informações Software "Mundo real"

Slide 12

Slide 12 text

O que esperamos "Mundo real" Software

Slide 13

Slide 13 text

O que acontece "Mundo real" Software

Slide 14

Slide 14 text

Viés técnico

Slide 15

Slide 15 text

O código Chuck Norris

Slide 16

Slide 16 text

No content

Slide 17

Slide 17 text

O teste do tempo

Slide 18

Slide 18 text

Não somos Chuck Norris!

Slide 19

Slide 19 text

Domain Driven Design

Slide 20

Slide 20 text

Domain Driven Design área de interesse onde o software será desenvolvido

Slide 21

Slide 21 text

Domain Driven Design área de interesse onde o software será desenvolvido o "como" estruturamos as partes internas do software para reﬂetir o domínio

Slide 22

Slide 22 text

Uma das principais idéias: design efetivo "Mundo real" Software

Slide 23

Slide 23 text

Passo 1 "Mundo real" Software

Slide 24

Slide 24 text

Passo 2 "Mundo real" Software

Slide 25

Slide 25 text

Passo 3 "Mundo real" Software

Slide 26

Slide 26 text

# consegui! "Mundo real" Software

Slide 27

Slide 27 text

Começando a modelar

Slide 28

Slide 28 text

Modelo Projeto Negócio Desenvolvedor Linguagem ubíqua Domínio

Slide 29

Slide 29 text

Modelo Projeto

Slide 30

Slide 30 text

Modelo Projeto

Slide 31

Slide 31 text

Modelo Projeto

Slide 32

Slide 32 text

Modelo Projeto Negócio Desenvolvedor Linguagem ubíqua Domínio

Slide 33

Slide 33 text

Parênteses: DDD Estratégico x DDD Tático

Slide 34

Slide 34 text

● Ao fazer as modelagens no Domain Driven Design, podemos atacar o domínio sob uma perspectiva macro e micro do problema: ○ o DDD estratégico: entender e separar o domínio como um todo em diversos contextos (contextos delimitados), cada um com a seu idioma / linguagem úbiqua ○ o DDD tático: busca representar em software / código cada um desses contextos com os building blocks

Slide 35

Slide 35 text

DDD Estratégico Imagem extraída da página: https://martinfowler.com/bliki/BoundedContext.html

Slide 36

Slide 36 text

Fim dos parênteses

Slide 37

Slide 37 text

Linguagem úbiqua ● Linguagem (termos, ações, papéis) sobre o conhecimento compartilhado / adquirido sobre domínio entre as partes do projeto ● Ela "permeia" todo o software e o seu processo de construção, devendo ser reﬂetida e evoluir com as interações entre os envolvidos na construção do modelo

Slide 38

Slide 38 text

Soft Skills Hard Skills

Slide 39

Slide 39 text

Soft Skills Comunicação Escalabilidade Hard Skills

Slide 40

Slide 40 text

Soft Skills Entrega de valor Comunicação Manutenção Escalabilidade Hard Skills

Slide 41

Slide 41 text

Soft Skills Empatia Entrega de valor Comunicação Manutenção Escalabilidade Testes Hard Skills

Slide 42

Slide 42 text

Pessoas Tecnologia

Slide 43

Slide 43 text

"Somos pagos para pensar, já escrever código, é de graça"

Slide 44

Slide 44 text

No content

Slide 45

Slide 45 text

Ao problema !!!

Slide 46

Slide 46 text

Mas primeiro...

Slide 47

Slide 47 text

Não existe bala de prata !!!!!!!!!!!

Slide 48

Slide 48 text

A primeira especiﬁcação

Slide 49

Slide 49 text

"O coiso deve ser ligado junto com o treco para conseguir a outra coisa" Primeira descrição de domínio

Slide 50

Slide 50 text

No content

Slide 51

Slide 51 text

"O coiso deve ser ligado junto com o treco para conseguir a outra coisa" Papéis

Slide 52

Slide 52 text

"O coiso deve ser ligado junto com o treco para conseguir a outra coisa" Ações

Slide 53

Slide 53 text

ligado com para conseguir

Slide 54

Slide 54 text

No content

Slide 55

Slide 55 text

Feedbacks e Round 2 !

Slide 56

Slide 56 text

"O coiso deve ser usado no GPS para conseguir calcular a rota" Round 2

Slide 57

Slide 57 text

No content

Slide 58

Slide 58 text

Feedbacks e Round 3 ! "Mas… o que é o coiso?"

Slide 59

Slide 59 text

"O endereço deve ser usado no GPS para conseguir calcular a rota" Round 3, a.k.a. o que é o coiso?

Slide 60

Slide 60 text

No content

Slide 61

Slide 61 text

Vitória !!!

Slide 62

Slide 62 text

Ok… mas e a estrutura do código?

Slide 63

Slide 63 text

DDD Tático: Building blocks

Slide 64

Slide 64 text

Building blocks Entidades Objetos de Valor Agregados Serviços Repositórios Factories

Slide 65

Slide 65 text

Building blocks "mais comuns"* Entidades Objetos de Valor Agregados Serviços Repositórios Factories

Slide 66

Slide 66 text

● Entidades: objeto com uma série de atributos deﬁnidos por uma identidade e linha de continuidade ● Objeto de valor: objeto com uma série de atributos, sem identidade e imutável Building blocks

Slide 67

Slide 67 text

"Um endereço é único no sistema e deve ter um logradouro, número, CEP, cidade e tipo (residência ou trabalho)" "Uma rota é um conjunto de instruções ordenadas, que descrevem a direção a seguir para o destino" Entidades X Objetos de Valor

Slide 68

Slide 68 text

Entidades

Slide 69

Slide 69 text

Objetos de valor

Slide 70

Slide 70 text

● Serviços: comportamentos do domínio que não se enquadram em entidades e em objetos de valor, não possuem estado ● Repositórios: serviço responsável por gerenciar o ciclo de vida das entidades na aplicação, persistir os dados de uma entidade em um mecanismo de armazenamento (banco de dados, arquivo, etc) Building blocks

Slide 71

Slide 71 text

Serviços

Slide 72

Slide 72 text

Repositórios

Slide 73

Slide 73 text

Ok… como eles se interligam?

Slide 74

Slide 74 text

No content

Slide 75

Slide 75 text

Exemplo: API Web Controllers Interactors / Serviços Entidades Repositórios External Clients ORMs ... Application Services

Slide 76

Slide 76 text

Controllers Interactors / Serviços Entidades Repositórios External Clients ORMs ... Application Services Infraestrutura Domínio Infraestrutura

Slide 77

Slide 77 text

Controller (Infra)

Slide 78

Slide 78 text

Controller (Infra)

Slide 79

Slide 79 text

Interactor / Serviço (Domínio)

Slide 80

Slide 80 text

Interactor / Serviço (Domínio)

Slide 81

Slide 81 text

Repositório (Domínio)

Slide 82

Slide 82 text

Interactor / Serviço (Domínio)

Slide 83

Slide 83 text

Entidade (Domínio)

Slide 84

Slide 84 text

Entidade (Domínio)

Slide 85

Slide 85 text

Cliente (Infra)

Slide 86

Slide 86 text

Cliente (Infra)

Slide 87

Slide 87 text

Controllers Interactors / Serviços Entidades Repositórios External Clients ORMs ... Application Services Infraestrutura Domínio Infraestrutura

Slide 88

Slide 88 text

That's all!

Slide 89

Slide 89 text

● Livros: ○ Domain Driven Design: Tackling Complexity in the Heart of Software ○ Implementing Domain-Driven Design ○ Domain-Driven Design Distilled ○ Clean Architecture: A Craftsman's Guide to Software Structure and Design ● Talks: ○ GOTO 2017 • DDD Today - Modeling Uncertainty • Vaughn Vernon ○ Eric Evans - Keynote: DDD Isn't Done: A Skeptical, Optimistic , Pragmatic Look Para saber mais...

Slide 90

Slide 90 text

Engenheiro de Software na Resultados Digitais Mestre em Ciência da Computação (foco em IA) pela USP Quem sou?

Slide 91

Slide 91 text

Engenheiro de Software na Resultados Digitais Mestre em Ciência da Computação (foco em IA) pela USP Pai coruja / zumbi Quem sou?

Slide 92

Slide 92 text

https://boards.greenhouse.io/resultadosdigitais

Slide 93

Slide 93 text

Obrigado! https://github.com/danielbdias https://speakerdeck.com/danielbdias https://twitter.com/danielbdias