Download to read offline
Finding balance of DDD while your application grows
- 1.
- 2. @carolkarklis 🏄♀️🍺💃 Software Developerat Magnetis Ruby e Elixir ❤️ Cats <3 Diversity and Inclusion 💖 Brazilian 🇧🇷
- 3. 01 Big picture of DomainDriven Design (DDD) schedule 02 Why practicing DDD? 03 Starting with DDD 04 Approaches for each scenario @carolkarklis
- 4. Motivation behind this talkcame from a tech event Photo by James Pond on Unsplash @carolkarklis
- 5. When is itthe right time to pay more attention in the code and architecture?
- 6. What is thebalance of software development?
- 7. Go horse Balance Code balanceOverengineering 🐴 💣
- 8. Goal of thistalk ■ Understand big picture of DDD ■ Be able to identify the current situation of business ■ Know the best approach given the current situation ■ Inspire and encourage the vision of bringing business value through code @carolkarklis
- 9.
- 10. DDD means DomainDriven Design
- 11. Business domain guidesproject development
- 12. Domain is agroup of things that company does to solve a problem
- 13. Domain is howthe company do their business
- 14.
- 15.
- 16.
- 17. Ubiquitous language Is oneof the pillars of Domain Driven Design
- 18. What is NOT ■Business language (jargons, terms, etc) Photo by Hans-Peter Gauster on Unsplash
- 19. What is NOT ■Business language (jargons, terms, etc) ■ Communication of domains experts Photo by Hans-Peter Gauster on Unsplash
- 20. What is NOT ■Business language (jargons, terms, etc) ■ Communication of domains experts ■ A way of naming things in the code Photo by Hans-Peter Gauster on Unsplash
- 21. What is NOT ■Business language (jargons, terms, etc) ■ Communication of domains experts ■ A way of naming things in the code ■ The way developers communicate about the system Photo by Hans-Peter Gauster on Unsplash
- 22. What is NOT ■Business language (jargons, terms, etc) ■ Communication of domains experts ■ A way of naming things in the code ■ The way developers communicate about the system ■ Communication about how the system should work (speculative) Photo by Hans-Peter Gauster on Unsplash
- 23. "The practice ofbuilding up a common, rigorous language between developers and users" Eric Evans
- 24. Ubiquitous language It isbased on domain model and express how the system works in an understandable way for everyone in the team A language about a shared knowledge of domain made by the team
- 25. Code that expresseswhat the domain does
- 26. "When implementing DDD,is expected that code design is questioned" Vaughn Vernon, from the book Implementing Domain-Driven Design
- 27. Why practicing DDD? (orhow to convince your team to dedicate time in this practice)
- 28. Photo by BenjaminBehre on Unsplash Decrease of knowledge island
- 29. Photo by NeONBRANDon Unsplash A precise and understandable definition of the business being developed
- 30. Photo by SabinePeters on Unsplash Code maintenance gets easier and less expensive
- 31. Photo by BradBarmore on Unsplash Continuous modeling of the system
- 32. Photo by NESAby Makers on Unsplash More efficient development due the use of ubiquitous language
- 33. I believe thateveryone can benefit from practicing DDD
- 34. But the investmentin DDD will depend on company moment
- 35. Investments takes time The definitionof investment is to apply resource, time and effort in exchange of something later. You must consider if the team is willing to invest in building better software.
- 38.
- 41. What is thescenario of your system today?
- 42. statement The system iscompletely guided by data and you can classify it as a CRUD solution (create, read, update, delete). Your team only needs a pretty interface for data manipulation. scenario #1
- 43. statement The system iscompletely guided by data and you can classify it as a CRUD solution (create, read, update, delete). Your team only needs a pretty interface for data manipulation. scenario #1 diagnosis You don't need to invest time and effort from your team to practice DDD. That doesn't mean you should not worry about code quality.
- 44. statement The system requiresonly 30 or less business operations, is probably very simple to have a overview of the system. This means that your application don't have more than 30 use cases (methods), and each one of them have minimal business rules. Because of that, you don't feel lack of control by business complexity. This is a common scenario for startups doing their MVP. scenario #2
- 45. statement The system requiresonly 30 or less business operations, is probably very simple to have a overview of the system. This means that your application don't have more than 30 use cases (methods), and each one of them have minimal business rules. Because of that, you don't feel lack of control by business complexity. This is a common scenario for startups doing their MVP. scenario #2 diagnosis You could even have a challenge in your mind right now, but practicing DDD is a high cost because you didn't feel the pain of complexity yet. Maybe is the moment to gather domain experts and evolve the ubiquitous language.
- 46. What you cando ■ Evolve ubiquitous language ■ Use a tool that analyzes the code (rubocop, code climate, source level, etc) ■ Make an organized mess ■ Analyze software metrics like Churn vs Complexity
- 47. How to startbuilding ubiquitous language
- 48.
- 49. Create a glossary ofterms that are relevant Photo by You X Ventures on Unsplash
- 50. Try to finda knowledge in common
- 51. Document flow from productand technical point of view
- 52. Use tools toanalyze code
- 54. Analyze software metrics Churnvs Complexity
- 55. Churn It is ameasure of how often a file changes. Files that change more have bigger churn.
- 56. Complexity Usually is calculatedby Cyclomatic Complexity, which calculates the quantity of independent paths your code have (control transferences, logical sequences, etc)
- 58.
- 59.
- 60. Make an organizedmess Talk made by Sandi Metz: "Go ahead, make a mess"
- 62.
- 63.
- 64.
- 65.
- 66. Public API Sandi Metz expose Privatebehaviour
- 67. Public API Sandi Metz expose Privatebehaviour hide
- 68. Public API Sandi Metz expose Privatebehaviour hide Dependencies Dependencies
- 69. Public API Sandi Metz expose Privatebehaviour hide Dependencies Dependencies minimize
- 70. Public API Sandi Metz expose Privatebehaviour hide Dependencies Dependencies minimize move
- 72. "What's the futurecost of doing nothing now?" Sandi Metz, from talk "Go ahead, make a mess"
- 73. statement Let's say thatyou moved from 30 to 40 features and your starting to question complexity of things that need to be done. The system may not be maintained by an unique team, but by multidisciplinary teams. You are thoughtful about product evolution inside each team, and questioning if is possible to keep a stable system with code quality and reliable architecture. scenario #3
- 74. statement Let's say thatyou moved from 30 to 40 features and your starting to question complexity of things that need to be done. The system may not be maintained by an unique team, but by multidisciplinary teams. You are thoughtful about product evolution inside each team, and questioning if is possible to keep a stable system with code quality and reliable architecture. scenario #3 diagnosis You are coming close to the point where there is a real benefit in making code design: The benefit of productivity and being happy. Your team should start talking about code design (including DDD)
- 75. What you cando ■ If possible, distribute senior people across the teams, ensuring that the team have at least one person with experience in designing code (and failing) ■ Make periodical checks to talk about code quality and architecture (with team leaders). Like a code therapy. ■ Make fishbowls/meetups with product managers and developers to talk about it and analyze opportunities. ■ Start DDD with Strategic Modeling, never Tactical Patterns
- 76. Start practicing DDDwith Strategic Modeling Don't start with tactical patterns. For real.
- 77. Strategic Modeling vsTactical
- 78. Strategic Modeling givesyou boundaries and clear definition of your system
- 79. Strategic Modeling ■ Ubiquitouslanguage ■ Defining domain and subdomain ■ Defining bounded contexts ■ Context maps
- 80. Defining bounded contexts It'sa component so important as ubiquitous language when practicing DDD Is how DDD deals with models of big subdomains: Separating they by business intentions.
- 81.
- 82.
- 83.
- 84. exercise ■ Make alist of every subdomain you remember in your routine ■ Make a list of bounded contexts ■ Use a template to understand how bounded contexts communicate between them. ■ Do it and redo it as many times as necessary
- 85. statement Too many peopleand features to be managed. Requirements change and this requires lot of effort from the team in thinking about how to maintain current code and still make the necessary changes without breaking the system. scenario #4
- 86. statement Muitas pessoas efeatures para serem administradas. Os requisitos mudam e isso requer muito esforço do time em pensar como manter o código atual e ainda fazer as mudanças necessárias sem que outras coisas quebrem no sistema. scenario #4
- 87. statement Too many peopleand features to be managed. Requirements change and this requires lot of effort from the team in thinking about how to maintain current code and still make the necessary changes without breaking the system. scenario #4 diagnosis The time has come and you should invest in code design and practice DDD as much as possible. It's time to plan system changes.
- 88. statement Too many peopleand features to be managed. Requirements change and this requires lot of effort from the team in thinking about how to maintain current code and still make the necessary changes without breaking the system. scenario #4 diagnosis Chegou o momento esperado de investir em design de código e praticar DDD o quanto for possível. É hora de planejar mudanças no seu sistema.
- 89. What you cando ■ Collect all the effort from Strategic Modeling to use tactical patterns ■ Make a plan and focus on execution
- 90.
- 91. What software resourcesalready exist and can be reused?
- 92. What software resourceswill need to be created from scratch?
- 93. How many effortwe want to put in these resources that are being created from scratch?
- 94. Is there anyintegration between contexts that will need to be made from scratch too?
- 95. Strategic Modeling +Tactical Pattern
- 96. Tactical Patterns They arealso more practical than Strategic Modeling. It is worth mentioning that these patterns are applied within a bounded context. Resources closer to the code
- 97. A few patterns ■Value Objects ■ Entities ■ Domain Services ■ Repositories ■ Aggregates
- 98. Purpose of eachpattern
- 99. Patterns of relationship betweenbounded contexts ■ Shared Kernel ■ Customer/Supplier ■ Conformist ■ Partner ■ Anti Corruption Layer
- 100. Think carefully beforechoosing
- 101. Think carefully beforechoosing
- 102. Content about DDD ImplementingDDD, Vaughn Vernon Tactical Domain Driven Design Strategic Practices of DDD
- 103. Code is onlya way of bringing more value to the business
- 104. Code is onlya tool to help people
- 105.
Editor's Notes
- #11 É um jeito de fazer código
- #13 Is how the company do their business
- #14 Is how the company do their business
- #34 teste
- #35 teste
- #37 A verdade é que nós desenvolvedores somos péssimos pra identificar quando algo começa a ficar complexo
- #41 Nesse ponto tudo muda. Se o time não conseguir pegar tempo pra fazer um bom design,a performance começa a cair porque o sistema vai ficando mais engessado e difícil de modificar. Com um bom design, a performance fica mais constante e é possível ter mais entregas do que um sistema com nenhum ou péssimo design
- #49 Não precisa ser algo formal e nem muito organizado. Você pode pegar um fluxo e pedir para o especialista explicar. Por exemplo: Como funciona o fluxo de resgate?
- #51 É ISSO que você quer extrair da conversa: conceitos e palavras em comum. É assim que você testa se a linguagem do seu código reflete a realidade, e é assim que você constrói a linguagem ubíqua
- #52 Depois dessa conversa, documente ela no papel. Como esse fluxo funciona? O que é importante de ser dito sobre ele? A ideia não é manter uma documentação 100% fiel ao código o tempo todo, mas sim extrair os conhecimentos da reunião pra algo mais duradouro Depois de documentar o fluxo, envie para os especialistas e outros desenvolvedores. Esse é um ótimo exercício
- #53 Falar do rubocop e source level
- #55 Falar do rubocop e source level
- #61 Falar do rubocop e source level
- #76 Fazer fishbowls com o time de dev pra discutir sobre qualidade de código e espalhar conhecimento em design Se possível, fazer com que cada time tenha pelo menos uma pessoa com experiência em design de código Fazer checks periódicos Aproveite a oportunidade de lançar uma feature para fazer ela do zero, e não refatorar algo que vc já tem dificuldade de usar Não deixe a discussão sobre produto longe de refactor/design de código. Quanto mais perto, quanto mais vc mostrar a preocupação para os PM's, mais fácil Tentar encaixar o Shapeup aqui
- #81 DDD deals with large models by dividing them into different Bounded Contexts and being explicit about their interrelationships.
- #82 Vamos pensar nesse domínio: Ele tem intenções e contextos diferentes. O que um usuário significa em cada um desses subdomínios? Por exemplo, o termo CLIENTE pode ter vários significados Quando o usuario tá na vitrine, é uma coisa Quando faz o pedido, outra No pedido é bem limitado, o CLIENTE representa pouca coisa: eu só quero saber o tipo de pagamento e um endereço de entrega dele Agora vamos falar de intenções QUal a intenção de tudo isso? Vender um produto? Quase tudo é sobre vender um produto A vitrine existe porque ela quer que você compre. A experiência que voce tem com pedido e entrega pode fazer você comprar mais. Contabilidade é consequencia da compra Mas eu diria que a intenção do ESTOQUE é diferenciada de todas as outras. A intenção de negócio pra existencia do estoque é ter visibilidade do que se tem disponível a venda. A quantidade das coisas pra serem vendidas. Isso pode ajudar a definir o que entra numa promoção, por exemplo. São intenções diferentes. Então, nesse exemplo, eu vou separar o estoque dos outros, como bounded contexts diferentes.
- #83 Its almost certain that terms and meanings collide in the domain. For example, the term customer must have multiple meanings. When a user is browsing the catalog, customer means one thing. When placing an order, it means something else. Here's why: WHen browsing catalog, customer is being used in the context of previous purchase, loyalty, product availability, discounts. On the order, however, customer has a limited meaning. Customer means very little comparing to catalog: it's payment terms, ship-to address Nesse exemplo mais simples, a gente poderia dizer que a intenção de quase tudo que tá sendo exposto aí é vender um produto. Ponto. A vitrine existe porque ela quer que você compre. A experiência que voce tem com pedido e entrega pode fazer você comprar mais. Contabilidade é consequencia da compra Mas eu diria que a intenção do estoque é diferenciada de todas as outras. A intenção de negócio pra existencia do estoque é ter visibilidade do que se tem disponível a venda. A quantidade das coisas pra serem vendidas. Isso pode ajudar a definir o que entra numa promoção, por exemplo. São intenções diferentes. Então, nesse exemplo, eu vou separar o estoque dos outros, como bounded contexts diferentes.
- #84 Its almost certain that terms and meanings collide in the domain. For example, the term customer must have multiple meanings. When a user is browsing the catalog, customer means one thing. When placing an order, it means something else. Here's why: WHen browsing catalog, customer is being used in the context of previous purchase, loyalty, product availability, discounts. On the order, however, customer has a limited meaning. Customer means very little comparing to catalog: it's payment terms, ship-to address Nesse exemplo mais simples, a gente poderia dizer que a intenção de quase tudo que tá sendo exposto aí é vender um produto. Ponto. A vitrine existe porque ela quer que você compre. A experiência que voce tem com pedido e entrega pode fazer você comprar mais. Contabilidade é consequencia da compra Mas eu diria que a intenção do estoque é diferenciada de todas as outras. A intenção de negócio pra existencia do estoque é ter visibilidade do que se tem disponível a venda. A quantidade das coisas pra serem vendidas. Isso pode ajudar a definir o que entra numa promoção, por exemplo. São intenções diferentes. Então, nesse exemplo, eu vou separar o estoque dos outros, como bounded contexts diferentes.
- #97 is a set of technical resources used in the construction of your Domain Model, these resources must be applied to work in a single Bounded Context.