DDD beyond the infamous repository pattern - GeeCon Prague 2018
•
7 j'aime•1,027 vues
DDD is often misinterpreted in so many ways. Many teams focus only on the tactical patterns, or even consider repositories as mere glorified DAO's and forget about all the other concepts that really matter: the focus on the business domain, modeling in code, and the concept of Bounded Contexts. In this talk for junior and senior developers alike, we'll clarify the few most important building blocks of DDD. We will also illustrate how practicing DDD actually looks like. This talk is the perfect opportunity to get started on DDD on solid grounds!
Recommandé
Recommandé
Contenu connexe
Similaire à DDD beyond the infamous repository pattern - GeeCon Prague 2018
Similaire à DDD beyond the infamous repository pattern - GeeCon Prague 2018 (20)
Plus de Cyrille Martraire
Plus de Cyrille Martraire (13)
Dernier
Dernier (20)
DDD beyond the infamous repository pattern - GeeCon Prague 2018
- 1. Prague, 18-19 October 2018 Domain-Driven Design Beyond the infamous repository pattern Cyrille Martraire @cyriux
- 2. Once upon a time 2001
- 4. DAO
- 5. With DTO
- 8. But now we got better… 8
- 9. 2003
- 10. DAO Repository
- 13. DDD NOT!
- 14. So what is DDD?
- 19. DDD?
- 24. OFTENMISTAKEN No Tool Needed CQRS: most popular WELL-respected
- 25. @yanaga
- 26. @zpapierski
- 27. @@mtnygard
- 29. My DDD Map 29 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
- 30. DDD Map 30 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
- 31. DDD Essentials Curious about the domain Talking the Domain Language Focus on Core Domain Modeling == Code Strategic Design (+ techniques to achieve that) 31
- 32. Example PLZ!
- 33. Domain Experts!
- 34. Please add a discount code to the purchase!
- 35. You mean the shopping cart?
- 36. Yes, this is what I meant (of course)
- 37. Ok, so let’s add a voucher field to the class ”BasketModel”
- 40. problem Systematic Translation (waste of time + confusion as-a-service)
- 41. solution Ubiquitous Language talk the domain language
- 42. Ubiquitous Language • Naming •Searchable •Easy to pronounce •No abbreviation • Definitions •Shared definition •Understand, not just a vocabulary h#p://www.visualdicDonaryonline.com/house/structure-house/stairs.php
- 46. Everyone talking the Domain Language Everywhere (even in the code) 46
- 48. Extract a word cloud from your code BAD
- 49. Extract a word cloud from your code Better
- 50. null DDD style of code? • No technical pollu5on • Spring, Hibernate, logger • javax.* • SQL
- 51. [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
- 53. So you mean DDD is primarily just talking business domain? 53
- 57. When to apply DDD? 57
- 58. WeWant:
- 60. Rich business domain 60 Risk is in the domain
- 61. Apply DDD! 61
- 63. Differentiating business domain 63 Value is in the domain
- 64. Apply DDD! 64
- 66. Go CRUD! 66
- 67. Focus on the Core Domain 67
- 69. Apply DDD! 69
- 71. BUY
- 74. I only care about Kubernetes
- 77. Oh, this domain is really cool!
- 78. Oh, this domain is really cool! I’d like to know it better!
- 80. Scenarios Intent
- 82. BDD: probably your best friend to start DDD
- 83. Domain Language (you can be dogmatic on that)
- 86. Example PLZ!
- 89. Kitten kitty = new Kitten(Attitude.ROCK_STAR); Microphone mike = new Microphone(); kitty.sing(mike); system.out.println(mike.playBack()); //”mew mew meeew”
- 92. Learn the business domain by reading the code 92
- 93. Learn the business domain by reading the code 93 and running the code
- 94. Domain Modeling (invest where it matters)
- 95. HOW?
- 96. Domain modeling toolbox (not the important stuff) 96
- 98. 3 kinds of classes: Value Objects Entities Services 98
- 99. Equality by value Value Object
- 100. « DayShi= by -2 WORKING days » No geGer/seGer Immutable Value Object
- 101. Behavior!
- 102. Perfect Value Objects: Java Enums Scala Case Classes
- 104. Not a value Not an enDty ”Giving the illusion of an in-memory collec6on” Domain Services h#p://www.andeka.co.cc/2011/07/postbox-251.html
- 108. Persistence Ignorance •You can oYen defer decisions about persistence •Your domain must not care
- 109. Repository
- 112. Strategic Design 112
- 113. Strategic Design(usefull all the time)
- 114. 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.
- 115. 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!
- 116. Please add a new discount mode
- 117. Where do I add that?
- 118. I know: I’ll add the code in the MainController class!
- 119. MainController 28 fields here … 245 methods here … 6422 lines
- 121. problem Code Gravity big stuff attracts even more stuff and gets bigger @carlopescio
- 122. solution Domain Boundariesbusiness domain as code modules, literally
- 124. Refactor based on your domain understanding 124
- 126. We want IT alignment blabla…
- 127. We want IT alignment blabla…
- 128. I know how to do that! Once you know DDD…
- 131. Pre-NegotiationListing) B2BOrdering Fraud Détection Payment Sourcing Distribution Rates Grid RealTime Prices Gift Cards Content & Comparators Sales Promotion Acquisition TV Campaigns Online Ads Company Rating Product Reviews Shopping Cart Catalogue Search Categories Tags PartnershipsSecondary Listing Internal Purchasing Rates CrossSales Navigation SEO Marketing
- 133. Hey! Companies have a different billing address!
- 134. I know: let’s add it with a flag!
- 136. 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 =
- 137. 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
- 139. problem Code Mess by lack of domain understanding
- 140. solution Bounded Contexts split 1 big model by sub-domains
- 141. Split by business domains 141
- 148. Customer addressLine zipcode city date amount user Account addressLine zipcode city Recipient + + Default value: billing address = shipping address
- 151. Evolve differently in the long term 151
- 156. What is 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
- 157. Different perspectives My book is not your book
- 158. Fragmenting your model Separate models = simpler than single model
- 159. @zpapierski
- 160. Conflicting views suggest several contexts “I don’t need all these data for my use-case, I just need these 3 fields”
- 161. 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
- 162. 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
- 163. — @zpapierski
- 166. by the way...
- 168. loosely-coupled, service-oriented architecture with bounded context. Adrian Cockcroft Microservices!
- 170. DDD Framework?
- 171. DDD Framework?
- 172. What language?
- 173. What language? Does not matter (but easier with F#)
- 174. Is DDD for you? • Do you feel close to XP? • Do you love distributed caches?
- 175. How to go further? Read the blue book Read Martin Fowler Try Event Storming
- 183. Micro-Services
- 184. WHY microservices? INDEPENDENT Work Streams GRANULAR Independent Deployments Plus recent history has proven we don’t have the DECOUPLING discipline FAULT-isolation
- 186. Sub-Domains Init CP purpose & EC Date Team & Collaboration StrucKyc FATCA Embargo Bundle Limit Check Integration Risk Sharing Federation Pricing Integration CO IFRS9 classification Volcker classification Mandate NDA internal billing PoA AML Liq Integration Legal Blacklist Hedging Approval Pre KyC Closing Prospects Ref WH Tax, Margin, Fees
- 187. tags: ReadModel, WriteModel, Projection, Service, BFF, Infra
- 188. Microservices in practice Each microservice has its own private logical ”database”: CREATE DATABASE microservicename; Microservices expose API’s and consume other services http / REST / Json Most microservices are built on a Microservice Chassis Spring Boot / Spring Cloud Suite
- 189. Shopping Cart Shipping insurance Anti Fraud Discount Shipping Cost Estimation Federated Micro-services … XX Id, & Version, XX Id, YY Id Z-specific data & behaviors, for each Y of X T-specific data & behaviors, for each Y of X U-specific data & behaviors, for each Y of X V-specific config (input) for each Y of X Easy to extend by addition of a new federated service
- 191. Production-ready Microservices Each service exposes health checks & metrics /health /metrics /info (built-in Spring Boot Actuator) Each service produces semlogs used by monitoring ELK + Worker Each service is instrumented for distributed tracing ZIPKIN (Sleuth)
- 192. Zipkin - your new debugger
- 194. WHY Event-Driven Architecture? DISTRIBUTE data across services for fast Eventual Consistency TEMPORAL Decoupling between services (reduced failure area) Events Senders and Receivers DON’T KNOW each other (Decoupling)
- 195. Event-Driven Architecture in practice One event bus with one shared topic RabbitMQ Everyone Broadcasts to Everyone Exchange type: Fanout (or Headers) Choreography over Orchestration No central coordinator, control is decentralized
- 196. Choreography over orchestration Init Pricing V UX T Update Amt Command Amt Updated X Updated Pricing Failed T Planed V ToReview
- 199. Event Sourcing: a persistence style (events as private schema) Event-Driven Architecture: an integration style (events as published contracts) Can change whenever I want Can never change once used
- 200. Contracts are forever! Robustness rules • MUST_IGNORE events & fields you don’t know • NEVER_REMOVE an existing field or event • ALWAYS_ADD new fields for changes protobuf, avro Consumer-Driven Contracts
- 201. Which language in the events? B ACL B Events A Events See: DDD /Context Mapping
- 206. Passenger safety Propulsion Car to ground link
- 207. Passenger safety Propulsion Car to ground link DDD / Bounded Contexts!