![[Object Calisthenics]
1. Wrap all primitives and strings
2. Use only one dot per line
3. Don’t abbreviate
4. Keep all clas...](https://image.slidesharecdn.com/dddforreal-180321174517/75/ddd-for-real-35-2048.jpg?cb=1668291835)
Serverless ddd
Your SlideShare is downloading.
×
More Related Content
Similar to DDD for real (20)
More from Cyrille Martraire (13)
Recently uploaded (20)
DDD for real
- 1. Domain-Driven Design For Real Cyrille Martraire @cyriux
- 2. 1968
- 3. Banker & Programmer
- 4. ”In 1968 DDD was a tautology” David West, DDD Europe 2017
- 5. NATO Software Engineering Conference 1968
- 6. business analyst software developer
- 7. DDDBusiness Expertise Software Expertise
- 8. Passionate developer PARIS Since 1999 @cyriux Cyrille Martraire
- 9. Paris Software Craftsmanship Community http://www.meetup.com/paris-software-craftsmanship/
- 10. TDD BDD DDD Legacy
- 11. DDD?
- 12. h"p://www.virtual-genius.com/blog/post/Domain-Driven-Design-Immersion-Course-e28093-Part-5.aspx
- 13. Seniors Developers h"p://www.thisisio.ie/blog/arDcle/149/hiring_senior_developer
- 14. OFTENMISTAKEN No Tool Needed CQRS: most popular WELL-respected
- 15. My DDD Map 21 Modeling == Code Strategic Design Bounded Context Context Mapping CQRS / EC large-scale structures Tactical Design Value Object Entities Repository Aggregate (patterns) Domain Events Focus on Core Domain Ubiquitous Language (BDD) Hexagonal Architecture FP + OO style Immutable Side-Effect-Free Patterns Monoids Bubble Context & Legacy Emerging Design
- 16. DDD Map 22 Modeling == Code Strategic Design Bounded Context Context Mapping CQRS / EC large-scale structures Tactical Design Value Object Entities Repository Aggregate (patterns) Domain Events Focus on Core Domain Ubiquitous Language (BDD) Hexagonal Architecture FP + OO style Immutable Side-Effect-Free Patterns Monoids Bubble Context & Legacy Emerging Design
- 17. DDD Essentials Curious about the domain Talking the Domain Language Focus on Core Domain Modeling == Code Strategic Design (+ techniques to achieve that) 24
- 18. Example PLZ!
- 19. Domain Expert
- 20. Please add a discount code to the purchase!
- 21. You mean the shopping cart?
- 22. Yes, this is what I meant (of course)
- 23. Ok, so let’s add a voucher field to the class ”BasketModel”
- 24. Purchase Shopping Cart BasketModel 32
- 25. problem Systematic Translation (waste of time + confusion as-a-service)
- 26. solution Ubiquitous Language talk the domain language
- 27. Ubiquitous Language • Naming •Searchable •Easy to pronounce •No abbreviation • Definitions •Shared definition •Understand, not just a vocabulary
- 28. Everyone talking the Domain Language Everywhere (even in the code) 37
- 29. Everyone talking the Domain Language Everywhere (even in the code) 38
- 30. Everyone talking the Domain Language Everywhere (even in the code) 39
- 31. 90% Business Domain Language here
- 32. Extract a word cloud from your code BAD
- 33. Extract a word cloud from your code Better
- 34. null DDD style of code? • No technical pollu5on • Spring, Hibernate, logger • javax.* • SQL
- 35. [Object Calisthenics] 1. Wrap all primitives and strings 2. Use only one dot per line 3. Don’t abbreviate 4. Keep all classes small 5. Don’t use any classes with more than two instance variables 6. Use first-class collections 7. Don’t use any getters/setters/ properties
- 36. 45 Tactical Patterns Value Objects Entities Domain Services Domain Events Repositories
- 37. Ubiquitous Language everywhere 47
- 38. So you mean DDD is primarily just talking business domain? 48
- 39. Ubiquitous Language everywhere 50 @cyriux
- 40. https://leanpub.com/livingdocumentation BUY MY BOOK!
- 41. When to apply DDD? 52
- 42. WeWant:
- 43. WeWant: Anapptodetect paymentfrauds
- 44. Rich business domain 55 Risk is in the domain
- 45. Apply DDD! 56
- 46. WeWant: Afeaturetobeatour competition
- 47. Differentiating business domain 58 Value is in the domain
- 48. Apply DDD! 59
- 49. WeWant: AnotherTODOlistapp
- 50. Go CRUD! 61
- 51. Focus on the Core Domain 62
- 52. Differentiating to the business?
- 53. Apply DDD! 64
- 54. Not differentiating?
- 55. BUY
- 56. Domain Curiosity 67
- 57. I only care about Kubernetes
- 58. Hey! Finance is cool!
- 59. Oh, this domain is really cool!
- 60. Oh, this domain is really cool! I’d like to know it better!
- 61. Start with Examples 74
- 62. Scenarios Intent
- 63. Scenarios Concrete examples
- 64. BDD: probably your best friend to start DDD
- 65. @cyriux
- 66. Modeling == Code 79
- 67. Example PLZ!
- 68. Please add a new discount mode
- 69. Where do I add that?
- 70. I know: I’ll add the code in the MainController class!
- 71. MainController 28 fields here … 245 methods here … 6422 lines
- 72. problem Code Gravity big stuff attracts even more stuff and gets bigger @carlopescio
- 73. solution Domain Modeling business domain as code, literally
- 74. Payment … Discounting … Add the feature only here
- 75. Refactor based on your domain understanding 89
- 76. Domain-Driven Refactoring 90
- 77. Domain modeling in practice 91
- 78. *NOT* UML/MDA! h"p://depinfo.u-cergy.fr/projets/close2u/fr/tag/uml/
- 79. Kitten kitty = new Kitten(Attitude.ROCK_STAR); Microphone mike = new Microphone(); kitty.sing(mike); system.out.println(mike.playBack()); //”mew mew meeew”
- 80. Good modeling? 96
- 81. Learn the business domain by reading the code 97
- 82. Learn the business domain by reading the code 98 and running the code
- 83. We want IT alignment blabla…
- 84. We want IT alignment blabla…
- 85. I know how to do that! Once you know DDD…
- 86. Functional Area | Code Module 103 1-to-1
- 87. Example PLZ!
- 88. 105 decision making vehicle dispatching cyclic dependency!
- 89. 106 decision making vehicle dispatching cyclic dependency!
- 90. 107 decision making vehicle dispatching Which one to cut?
- 91. A business domain Decision 108
- 92. 109 decision making vehicle dispatching 1 business decision
- 93. 110 decision making vehicle dispatching technical impact
- 94. Strategic Design 113
- 95. Bounded Contexts Explicitly define the context within which a model applies. Explicitly set boundaries in terms of team organization, usage within specific parts of the application, and physical manifestations such as code bases and database schemas. Keep the model strictly consistent within these bounds, but don’t be distracted or confused by issues outside.
- 96. Bounded Contexts Explicitly define the context within which a model applies. Explicitly set boundaries in terms of team organization, usage within specific parts of the application, and physical manifestations such as code bases and database schemas. Keep the model strictly consistent within these bounds, but don’t be distracted or confused by issues outside. Example PLZ!
- 97. Customer addressLine zipcode city …
- 98. Hey! Companies have a different billing address!
- 99. I know: let’s add it with a flag!
- 100. Purchase addressLine zipcode city has2AddressesFlag addressLine2 zipcode2 city2
- 101. Customer addressLine zipcode city has2AddressesFlag addressLine2 zipcode2 city2 If (! has2AddressesFlag) billing address line = … billing zip code = billing city = else billing address line = … billing zip code = billing city =
- 102. Customer addressLine zipcode city has2AddressesFlag addressLine2 zipcode2 city2 If (! has2AddressesFlag) billing address line = … billing zip code = billing city = else billing address line = … billing zip code = billing city = Everywhere
- 103. problem Code Mess by lack of domain understanding
- 104. solution Bounded Contexts split 1 big model by sub-domains
- 105. Split by business domains 125
- 106. Customer addressLine zipcode city date amount user Account addressLine zipcode city Recipient + + Shipping BillingShopping Cart
- 107. Shipping BillingShopping Cart
- 108. Shipping BillingShopping Cart Bounded Contexts by domain
- 109. Customer addressLine zipcode city date amount user Account addressLine zipcode city Recipient + + New names
- 110. customer ≠ account ≠ recipient 130 Near Synonyms
- 111. Customer addressLine zipcode city date amount user Account addressLine zipcode city Recipient + + Suggest Contexts
- 112. Customer addressLine zipcode city date amount user Account addressLine zipcode city Recipient + + Default value: billing address = shipping address
- 113. But… that’s massive duplication!
- 114. ”No Duplication” means ”Coupling”
- 115. Evolve differently in the long term 135
- 116. addressLine zipcode city Account Billing addressLine zipcode city Recipient Shipping
- 117. addressLine zipcode city contactName taxRegion Account Billing addressLine zipcode city Recipient Shipping
- 118. addressLine zipcode city contactName taxRegion Account Billing addressLine zipcode city doorCode availabilityTimeSlots Recipient Shipping
- 119. Purchase BillingUnit DeliveryRequest * * e.g. marketplace
- 120. DRY == Coupling Bounded Contexts: We decide to reduce coupling at the cost of some redundancy 140
- 121. What a book at Amazon? •Catalog: Picture, title, authors, rating, format (ebook or paper), category •Recommandation: List of books often bought together with it •Shipping: Dimensions, weight, international restrictions due to content •Shopping cart: Price, discount eligible •Customer review: List of (rating, review, review rating) •Book Search: title, isbn, authors •Search Inside!: full-text content, copyright- dealing policy
- 122. Different perspectives My book is not your book
- 123. colleague committer collaborator candidate friend peer
- 124. Polyglot persistence (random examples) •Catalog: NoSQL •Recommandation: Batch + GraphDB •Shipping: RDBMS •Shopping cart: RDBMS •Customer review: Cassandra •Book Search: Elastic Search •Search Inside!: Redis + CDN
- 125. Team organization •Catalog: Team 1 •Recommandation: Team 2 •Shipping: Team 3 •Shopping cart: Team 4 •Customer review: Team 5 •Book Search: Team 6 •Search Inside!: Team 7
- 126. by the way...
- 127. loosely-coupled, service-oriented architecture with bounded context.
- 128. loosely-coupled, service-oriented architecture with bounded context. Adrian Cockcroft Microservices!
- 129. DDD?
- 130. Identification au code Identification au métier
- 131. DDD Framework?
- 132. DDD Framework?
- 133. What language?
- 134. What language? Does not matter (but easier with F#)
- 135. Is DDD for you? • Do you feel close to XP? • Do you love distributed caches?
- 136. How to go further? Read the blue book Read Martin Fowler Try Event Storming
- 137. h"p://cathy313.centerblog.net/539-bisounours @cyriux
