Download as PDF, PPTX
![[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](https://image.slidesharecdn.com/dddgeecon-181024121251/85/DDD-beyond-the-infamous-repository-pattern-GeeCon-Prague-2018-51-320.jpg)
Uploaded byCyrille Martraire
DDD beyond the infamous repository pattern - GeeCon Prague 2018
The document discusses the evolution of Domain-Driven Design (DDD) since its inception, highlighting its essential components like strategic design, ubiquitous language, and tactical patterns. It emphasizes the importance of understanding the core business domain and collaborating closely with domain experts, while also addressing challenges such as domain modeling and code management. Additionally, it explores practical applications of DDD in modern software architecture, including microservices and event-driven design.
More Related Content
Similar to DDD beyond the infamous repository pattern - GeeCon Prague 2018
DDD beyond the infamous repository pattern - GeeCon Prague 2018
- 1. Prague, 18-19 October2018 Domain-Driven Design Beyond the infamous repository pattern Cyrille Martraire @cyriux
- 2. Once upon atime 2001
- 4.
- 5.
- 6.
- 8. But now wegot better… 8
- 9.
- 10.
- 11.
- 13.
- 14. So what isDDD?
- 16.
- 17.
- 18.
- 19.
- 21.
- 23.
- 24. OFTENMISTAKEN No Tool Needed CQRS:most popular WELL-respected
- 25.
- 26.
- 27.
- 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 aboutthe domain Talking the Domain Language Focus on Core Domain Modeling == Code Strategic Design (+ techniques to achieve that) 31
- 32.
- 33.
- 34. Please add a discountcode to the purchase!
- 35.
- 36. Yes, this iswhat I meant (of course)
- 37. Ok, so let’sadd a voucher field to the class ”BasketModel”
- 39.
- 40. problem Systematic Translation (waste of time+ confusion as-a-service)
- 41.
- 42. Ubiquitous Language • Naming •Searchable •Easyto pronounce •No abbreviation • Definitions •Shared definition •Understand, not just a vocabulary h#p://www.visualdicDonaryonline.com/house/structure-house/stairs.php
- 44.
- 45.
- 46. Everyone talking the Domain Language Everywhere (evenin the code) 46
- 47.
- 48. Extract a wordcloud from your code BAD
- 49. Extract a wordcloud from your code Better
- 50. null DDD style ofcode? • No technical pollu5on • Spring, Hibernate, logger • javax.* • SQL
- 51. [Object Calisthenics] 1. Wrapall 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
- 52.
- 53. So you mean DDDis primarily just talking business domain? 53
- 55.
- 56.
- 57. When to applyDDD? 57
- 58.
- 59.
- 60. Rich business domain 60 Riskis in the domain
- 61.
- 62.
- 63. Differentiating business domain 63 Value isin the domain
- 64.
- 65.
- 66.
- 67. Focus on the CoreDomain 67
- 68.
- 69.
- 70.
- 71.
- 72.
- 74. I only careabout Kubernetes
- 75.
- 77.
- 78. Oh, this domain is reallycool! I’d like to know it better!
- 79.
- 80.
- 81.
- 82. BDD: probably yourbest friend to start DDD
- 83. Domain Language (you can bedogmatic on that)
- 85.
- 86.
- 87.
- 89. Kitten kitty =new Kitten(Attitude.ROCK_STAR); Microphone mike = new Microphone(); kitty.sing(mike); system.out.println(mike.playBack()); //”mew mew meeew”
- 91.
- 92. Learn the businessdomain by reading the code 92
- 93. Learn the businessdomain by reading the code 93 and running the code
- 94. Domain Modeling (invest where itmatters)
- 95.
- 96. Domain modeling toolbox (notthe important stuff) 96
- 97.
- 98. 3 kinds ofclasses: Value Objects Entities Services 98
- 99. Equality by value ValueObject
- 100. « DayShi= by-2 WORKING days » No geGer/seGer Immutable Value Object
- 101.
- 102. Perfect Value Objects: JavaEnums Scala Case Classes
- 103.
- 104. Not a value Not an enDty ”Giving the illusionof an in-memory collec6on” Domain Services h#p://www.andeka.co.cc/2011/07/postbox-251.html
- 105.
- 106.
- 107.
- 108.
- 109.
- 112.
- 113.
- 114. Bounded Contexts Explicitly definethe 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 definethe 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 anew discount mode
- 117. Where do Iadd that?
- 118. I know: I’lladd the code in the MainController class!
- 119. MainController 28 fields here … 245methods here … 6422 lines
- 121. problem Code Gravity big stuffattracts even more stuff and gets bigger @carlopescio
- 122. solution Domain Boundariesbusiness domain ascode modules, literally
- 123.
- 124. Refactor based onyour domain understanding 124
- 125.
- 126. We want IT alignmentblabla…
- 127. We want IT alignmentblabla…
- 128. I know howto do that! Once you know DDD…
- 130.
- 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 ShoppingCart Catalogue Search Categories Tags PartnershipsSecondary Listing Internal Purchasing Rates CrossSales Navigation SEO Marketing
- 132.
- 133. Hey! Companies have a differentbilling address!
- 134. I know: let’sadd it with a flag!
- 135.
- 136. Customer addressLine zipcode city has2AddressesFlag addressLine2 zipcode2 city2 If (! has2AddressesFlag) billingaddress 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) billingaddress line = … billing zip code = billing city = else billing address line = … billing zip code = billing city = Everywhere
- 139. problem Code Mess by lackof domain understanding
- 140. solution Bounded Contexts split 1 bigmodel by sub-domains
- 141. Split by businessdomains 141
- 142.
- 143.
- 144.
- 145.
- 146.
- 147.
- 148.
- 149.
- 150.
- 151. Evolve differently inthe long term 151
- 152.
- 153.
- 154.
- 155.
- 156. What is abook 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 bookis not your book
- 158. Fragmenting your model Separatemodels = simpler than single model
- 159.
- 160. Conflicting views suggest severalcontexts “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: Team1 •Recommandation: Team 2 •Shipping: Team 3 •Shopping cart: Team 4 •Customer review: Team 5 •Book Search: Team 6 •Search Inside!: Team 7
- 163.
- 166.
- 167.
- 168. loosely-coupled, service-oriented architecture with bounded context. AdrianCockcroft Microservices!
- 170.
- 171.
- 172.
- 173. What language? Does notmatter (but easier with F#)
- 174. Is DDD foryou? • Do you feel close to XP? • Do you love distributed caches?
- 175. How to gofurther? Read the blue book Read Martin Fowler Try Event Storming
- 177.
- 182.
- 183.
- 184. WHY microservices? INDEPENDENT WorkStreams GRANULAR Independent Deployments Plus recent history has proven we don’t have the DECOUPLING discipline FAULT-isolation
- 185.
- 186. Sub-Domains Init CP purpose & ECDate 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 Eachmicroservice 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 serviceexposes 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 - yournew debugger
- 193.
- 194. WHY Event-Driven Architecture? DISTRIBUTE dataacross 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 inpractice 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 UpdateAmt Command Amt Updated X Updated Pricing Failed T Planed V ToReview
- 198.
- 199. Event Sourcing: a persistencestyle (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! Robustnessrules • 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 inthe events? B ACL B Events A Events See: DDD /Context Mapping
- 206. Passenger safety Propulsion Car toground link
- 207. Passenger safety Propulsion Car toground link DDD / Bounded Contexts!