Domain Driven Design com Python

  • View
    1.796

  • Download
    3

  • Category

    Software

Preview:

Citation preview

Domain Driven Design com Python

Frederico Cabral

Frederico Cabral

• Carioca

• Triatleta

• Primeiro software profissional em 2000

• Python, C#, Ruby

Nosso Cliente

Quero vender na WEB!!!Preciso de um programador RockStar!

Programador Contratado

Skills do Programador

• Mindset Ágil

• Manja dos paranuê de Django e Python

• PHD em Design Patterns

• Extremamente profissional

“Vamos lá garoto!" Preciso de solução de ecommerce revolucionária

NÃO! Tá achando que fazer um ecommerce é que nem abrir uma das suas lojinhas num shopping?

Pq não começamos apenas com um catálogo de produtos?

2 semanas depois…

Boa garoto! Você é fantástico

Vamos ver se você é bom mesmo! Agora quero que meu cliente feche a

compra direto pelo site

Claro! Ta duvidando de mim? Vai ficar melhor que o da Amazon

Preciso apenas de 1 mes

3 meses depois

Cadê a compra?

Preciso integrar com o meu sistema de estoque

Meus Deus! Tudo bem. Mas vou precisar de mais programadores

Pleno Pleno Estagiário

6 meses depois…

As coisas continuam acumulando

Preciso de sistema de Pagamento

Online e Integração com o

SAP

X

Qual foi o erro?

0

4.5

9

13.5

18

Janeiro Março Jun Setembro

Lead time

CATALOGO SISTEMA

CLIENTE DEV

CATALOGO

SISTEMA

COMPRA

CLIENTE DEV

0

1.25

2.5

3.75

5

Janeiro Março

Lead time

CATALOGO

SISTEMA

COMPRA

ESTOQUE

CLIENTE DEV

0

2.5

5

7.5

10

Janeiro Março Jun

Lead time

CATALOGO

SISTEMACOMPRA

ESTOQUE

PAGAMENTO

SAP

CLIENTE DEV

0

4.5

9

13.5

18

Janeiro Março Jun Setembro

Lead time

"Software Monolítico é o problema!!!"

SERÁ?

http://wrd.cm/1UV07Xo

Google Is 2 Billion Lines of Code And It’s All in One Place

Monolítico

Monolítico Microservices

TECNOLOGIANEGÓCIO GAP

–Melvin Conway’s Law - 1968

“Organizations which design systems are constrained to produce designs which are

copies of the communication structures of these organizations.”

NEGÓCIO TECNOLOGIA

ESSA PALESTRA

Como resolvemos isso?

–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.”

DomainSubdomains

Bounded ContextsUbiquitous Language

Domain

• Define o que a empresa faz

• É o motivo do seu software existir

• Faz parte do “Problem Space”

• Composto de vários Subdomains

Domain & Subdomains

Estoque

Contabilidade

Catalogo

Compras

Pagamento

Ubiquitous Language

OBRA

OBRA

Taxa

Prazo

Classificação

Reservar()

Ativo IPO

Taxa

Prazo

Classificação

Comprar()

Vender()

Ativo Renda Fixa

Código

Nome

Atividade

Comprar()

Vender()

Ativo Ações

CLASSE “ATIVO”

Ao invés disso Nós fazemos isso

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

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

Subdomains x Bounded Contexts

Estoque

Contabilidade

Catalogo

Compras

Pagamento

Subdomains x Bounded Contexts

Estoque

Contabilidade

Catalogo

Compras

Pagamento

Subdomains x Bounded Contexts

Estoque

Contabilidade

Catalogo

Compras

Pagamento

Podem existir Bounded Contexts não focados no negócio?

Estoque

Contabilidade

Catalogo

Compras

Pagamento

Authentication

Core

SuporteGenérico

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

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"

“O domínio muda o tempo todo. O seu Bounded Context precisa acompanhar essas mudanças”

– 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”

Context MapsProtegendo seu domínio de influencias externas

Compras

Estoque

Up

Down

ACL

ANTICORRUPTION LAYER

ProdutoProduto

EstoqueCompras

Estoque não deve conhecer a classe Produto que vem do Bounded de Context Compras!!!

ProdutoProduto

EstoqueCompras

ACL

Entity & Value ObjectsO coração do coração

Muitos atributos!!

Método para nome do clienteMétodo para endereço

Verbosidade

Value Object

Value Object

Nomes mais curtos

Value Objects são imutáveis!

Validação:Ex: Final deve ser maior que Inicial

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"

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

FactoriesQuando criar um objeto virou uma tarefa para Hércules

{

Dicas para Factories

• Usado para criar objetos complexos

• Pode acessar repositórios ou serviços

• Pode ser uma Factory Class ou um Factory Method

Domain Services

Regra de calculo de frete interage com vários objetos

Lembre das exceções!

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

RepositoryPq não me interessa onde estão os dados

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

Domain Event“Acontecimentos" empresariais

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

O maior risco de Domain Events

Diversos patterns

Python Puro!

Nenhuma dependência de frameworks

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

Ciclo

Failing Test Make the test pass

Refactor

TDD

Failing Feature

Make the Feature pass

BDD

DDD

Domain Learning

CORE

Entities e Value Objects

Factories, Services, Repository, Events, ACL

Django, Flask

Nunca é 100%!!!

Arquitetura Hexagonal

Trabalho num legadão!! DDD é impossível pra mim!!

Vai valer à pena!

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

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

DDD

• Colaboração!!

• Um meio de aproximar negócio e tecnologia

• Ágil

• Mantém a ideia artesanal do desenvolvimento de software

DDD é um mindset!

–Napoleon Hill

“Não devemos ter medo das novas ideias! Elas podem significar a diferença entre o

triunfo e o fracasso.”

OBRIGADO!

@fredportocabral

Recommended