Domain Driven Design com Python
19 gostaram8,824 visualizações
O documento discute a aplicação do Domain Driven Design (DDD) no desenvolvimento de soluções de software, especialmente em e-commerce, destacando a importância de alinhar a tecnologia com os conceitos de negócios. São abordados conceitos como bounded contexts, subdomínios e a necessidade de uma linguagem ubíqua para evitar a 'corrupção' técnica. O autor também oferece dicas práticas para a implementação do DDD e enfatiza a colaboração entre desenvolvedores e especialistas de domínio para alcançar sucesso em projetos complexos.
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.”