Domain Driven Design com Python
•
19 likes•8,728 views
Como diminuir o gap entre negócio e tecnologia e ainda por cima com Python. Palestra apresentada no The Developers Conference 2015 - Porto Alegre
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Domain Driven Design com Python
Similar to Domain Driven Design com Python (20)
Domain Driven Design com Python
- 1. Domain Driven Design com Python Frederico Cabral
- 2. Frederico Cabral • Carioca • Triatleta • Primeiro software profissional em 2000 • Python, C#, Ruby
- 4. Quero vender na WEB!!! Preciso de um programador RockStar!
- 6. Skills do Programador • Mindset Ágil • Manja dos paranuê de Django e Python • PHD em Design Patterns • Extremamente profissional
- 7. “Vamos lá garoto!" Preciso de solução de ecommerce revolucionária
- 8. NÃO! Tá achando que fazer um ecommerce é que nem abrir uma das suas lojinhas num shopping?
- 9. Pq não começamos apenas com um catálogo de produtos?
- 11. Boa garoto! Você é fantástico
- 12. Vamos ver se você é bom mesmo! Agora quero que meu cliente feche a compra direto pelo site
- 13. Claro! Ta duvidando de mim? Vai ficar melhor que o da Amazon Preciso apenas de 1 mes
- 14. 3 meses depois
- 15. Cadê a compra?
- 16. Preciso integrar com o meu sistema de estoque Meus Deus! Tudo bem. Mas vou precisar de mais programadores
- 18. 6 meses depois… As coisas continuam acumulando
- 19. Preciso de sistema de Pagamento Online e Integração com o SAP
- 20. X
- 21. Qual foi o erro?
- 22. 0 4.5 9 13.5 18 Janeiro Março Jun Setembro Lead time
- 29. 0 4.5 9 13.5 18 Janeiro Março Jun Setembro Lead time
- 30. "Software Monolítico é o problema!!!" SERÁ?
- 31. http://wrd.cm/1UV07Xo Google Is 2 Billion Lines of Code And It’s All in One Place
- 32. Monolítico
- 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.”
- 40. Domain • Define o que a empresa faz • É o motivo do seu software existir • Faz parte do “Problem Space” • Composto de vários Subdomains
- 43. OBRA OBRA
- 44. 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”
- 45. Ao invés disso Nós fazemos isso
- 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
- 48. Subdomains x Bounded Contexts Estoque Contabilidade Catalogo Compras Pagamento
- 49. Subdomains x Bounded Contexts Estoque Contabilidade Catalogo Compras Pagamento
- 50. Subdomains x Bounded Contexts Estoque Contabilidade Catalogo Compras Pagamento
- 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”
- 56. Context Maps Protegendo seu domínio de influencias externas
- 58. ProdutoProduto EstoqueCompras Estoque não deve conhecer a classe Produto que vem do Bounded de Context Compras!!!
- 61. Entity & Value Objects O coração do coração
- 62. Muitos atributos!! Método para nome do cliente Método para endereço Verbosidade
- 63. Value Object Value Object Nomes mais curtos
- 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
- 67. Factories Quando criar um objeto virou uma tarefa para Hércules
- 68. {
- 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
- 71. Domain Services
- 72. Regra de calculo de frete interage com vários objetos
- 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
- 75. Repository Pq não me interessa onde estão os dados
- 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
- 84. O maior risco de Domain Events
- 85. Diversos patterns Python Puro! Nenhuma dependência de frameworks
- 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
- 89. Trabalho num legadão!! DDD é impossível pra mim!!
- 92. Vai valer à pena!
- 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
- 97. DDD é um mindset!
- 98. –Napoleon Hill “Não devemos ter medo das novas ideias! Elas podem significar a diferença entre o triunfo e o fracasso.”