Download as PDF, PPTX
![[…] you may have only additive
changes. An additive change
always goes onto the end of the
record.
https://martinfowler.com/eaaDev/timeNarrative.html
Append-only
Compensation](https://image.slidesharecdn.com/dddeupatternsbeyondthebook-170226212945/85/DDD-patterns-that-were-not-in-the-book-151-320.jpg)
![[…] you may have only additive
changes. An additive change
always goes onto the end of the
record.
https://martinfowler.com/eaaDev/timeNarrative.html
Event-Sourcing-ish](https://image.slidesharecdn.com/dddeupatternsbeyondthebook-170226212945/85/DDD-patterns-that-were-not-in-the-book-152-320.jpg)
Uploaded byCyrille Martraire
DDD patterns that were not in the book
The document outlines a presentation by Cyrille Martraire on Domain-Driven Design (DDD), emphasizing the importance of exploring patterns beyond traditional DDD literature. Martraire presents 43 design patterns that can enhance understanding and application of DDD principles in various contexts, illustrating their relevance using examples from different domains. The talk promotes a broader perspective on software design, encouraging developers to learn from diverse patterns and to recognize that effective domain modeling requires knowledge beyond standard practices.
More Related Content
Similar to DDD patterns that were not in the book
DDD patterns that were not in the book
- 1.
- 2. Event Storming EventSourcing CQRS DDD
- 5.
- 6.
- 7.
- 8.
- 9. Passionate developer Deliberate Designer PARIS Since1999 @cyriux Cyrille Martraire
- 10. Paris Software Craftsmanship Communitysince 2011 http://www.meetup.com/paris-software-craftsmanship/
- 11.
- 12.
- 15.
- 16.
- 17.
- 18.
- 19.
- 20.
- 21. Eric Evans -Domain-Driven Design
- 24.
- 25.
- 26.
- 27.
- 28.
- 29.
- 30.
- 32. "The best wayto get the right answer on the Internet is not to ask a question, it's to post the wrong answer.” — Cunningham’s Law
- 33.
- 34.
- 35.
- 36. CHECKS Patterns 1. WholeValue 2. Exceptional cases (absence, error…) 3. Meaningless Behavior 4. Echo Back 5. Visible Implication 6. Deferred Validation 7. Instant Projection 8. Hypothetical Publication 9. Forecast Confirmation 10. Diagnostic Query Analysis Patterns
- 37. 25m + 10m = 35m (Custom Arithmetics) Whole Objectwith unit. Whole Object
- 38.
- 39.
- 40.
- 41. Cashflow Sequence + Cashflow Sequence = CashflowSequence Monoid
- 42. Could we say that? HotelBooking Jan26to27HotelBooking Jan27to29 HotelBooking Jan26to29 + = Monoid
- 43.
- 44.
- 45. CHECKS Patterns Traceability Normal display:652 MM USD EQV Diagnostic display: 622,456,325.07 USD + 3,624,878,450 JPY + 23,549.54 FRF
- 46. CHECKS Patterns 1. WholeValue 2. Exceptional cases (absence, error…) 3. Meaningless Behavior 4. Echo Back 5. Visible Implication 6. Deferred Validation 7. Instant Projection 8. Hypothetical Publication 9. Forecast Confirmation 10. Diagnostic Query Analysis Patterns
- 48.
- 50.
- 52.
- 54. In most domain models,most design patterns are technical noise. observer Singleton Factory Command VISITOR MEDIATOR Manager observer PROXY FACADE MEMENTO
- 55. But some design patternsalso describe business domain concepts and relations.
- 56.
- 57.
- 58. In a domainmodel, avoid pattern names in types names.
- 59.
- 60.
- 61.
- 62.
- 63.
- 64.
- 65.
- 66.
- 67. Strategy Pattern VAT VAT onnet price Not Applicable Calculation + Null Object
- 68. Null Object. No, youshould not replace every Null Object with Optional<T>
- 69. When to applya pattern? (or not)
- 70. IF Statements vs.Strategy pattern? Naming-Driven Whichever reveals the business domain best
- 71.
- 72.
- 73. Annotate classes withcustom annotations Stereotypes Annotations
- 74. Stereotypes Annotations Annotate classeswith custom annotations
- 75. Domain type namesare precious. They are for domain naming. Use annotations to document the stereotypes instead.
- 76. Stereotypes Annotations Annotate classeswith custom annotations Embedded Learning
- 77. Stereotypes Annotations Annotate withcustom annotations
- 78. Stereotypes Annotations Annotate withcustom annotations
- 79. Stereotypes Annotations Annotate domainclasses with custom annotations
- 80. Stereotypes Annotations Annotate domainclasses with custom annotations
- 81. And learn onthe job!
- 82.
- 83.
- 84.
- 85.
- 86.
- 87.
- 88.
- 89.
- 90.
- 91.
- 92.
- 93. 503010 … Flyweight We alwayswant to make multiplicity manageable
- 94.
- 95. -503010 … {10, 30,-50 …} Flyweight
- 96. {10, 30, -50…} ∑ = -10 Flyweight
- 97. ∑ = -10 manageable =aggregable, comparable… Flyweight
- 98. Equity Trading: Standard Stock MultipleTrades of the same $10M - $30M - - $50M x
- 99. $10M IBM $30M IBM AXA $50M Derivative Trading: MultipleContracts with a common structure
- 100.
- 101. $10M IBM $30M IBM AXA $50M The essenceof Flyweight x Many small, calculable elements One Blackbox IntrinsicExtrinsic
- 102.
- 103.
- 104.
- 105. I see whatyou mean… BUT no way, IT DOES NOT WORK from a legal perspective!
- 108.
- 109. FATAL OBJECTION as hint ofbounded Context!
- 110. Tip: Focus onone context = ≠ ≠
- 111. Works in thiscontext only = ≠ ≠ Legal Money Management
- 112. It works inmy context! = ≠ Transport Regulation Cargo Shipping
- 113. In what PERSPECTIVE could wesay that? Bounded Context
- 114.
- 115.
- 116.
- 117.
- 118. WHY U SO FASCINATED withpatterns?
- 119. Would you build Photoshoponly with IF statements and FOR loops?
- 121. for (...) if (...) if(..) { for... } else else while
- 122. for (...) if (...) if(..) { for... } else else while
- 123. You should have alook at design patterns!
- 124.
- 125.
- 126.
- 129.
- 130.
- 132.
- 133.
- 134. Traceability always points tothe Past. (aka. Consequences depend on the Cause)
- 135. ORDER BASKET PAYMENT RETURN time refers torefers torefersto causality e-commerce
- 136. Study the patterns. Digestthe principles. Apply to new domains.
- 138. CLAIM INSURANCE POLICY LOSS $ PAYMENT time refers torefers torefersto causality Insurance
- 139.
- 140.
- 141.
- 142. Bespoke, Custom. OK. Reinventing theWheel. NOT OK.
- 145.
- 146.
- 147.
- 148. Effectivity Range Agreement v1- effectivity: [01/2016, 01/2017[ Agreement v2 - effectivity: [01/2017, 01/2018[ Agreement v3 - effectivity: [01/2018, - [ Invariant: ranges are continuous & non- overlapping
- 149. Effectivity Range Agreement v1- effectivity: [01/2016, 01/2017[ Agreement v2 - effectivity: [01/2017, 01/2018[ Agreement v3 - effectivity: [01/2018, - [ 06/2017 Invariant: ranges are continuous & non- overlappingWhat version was effective on this date?
- 150. https://martinfowler.com/eaaDev/timeNarrative.html Bi-temporal Time Time hastwo dimensions in software!
- 151. […] you mayhave only additive changes. An additive change always goes onto the end of the record. https://martinfowler.com/eaaDev/timeNarrative.html Append-only Compensation
- 152. […] you mayhave only additive changes. An additive change always goes onto the end of the record. https://martinfowler.com/eaaDev/timeNarrative.html Event-Sourcing-ish
- 153.
- 154. Learn the history, notjust the end state. Learning Steps (à la Event Sourcing)
- 155. Know the HolyFamily :)
- 156.
- 157. Rebecca J. Wirfs-Brock FirstRDD paper in 1989!
- 158.
- 159.
- 161.
- 162.
- 163. Not just Code AlsoIdeas! Reuse all the things! And past insights
- 164. 164 A Business Transaction Aquantity of something (e.g. cash) A quantity of something else
- 165. 165 A Business Transaction Aquantity of something (e.g. cash) A quantity of something else Law: one side has to be cash
- 166. 166 A Business Transaction Aquantity of something (e.g. cash) A quantity of something else Received Date Paid Date Trade Date
- 167. Congratulations! You can nowreuse this domain insight!
- 168. WHY NOT WRITE YOUROWN PATTERNS?
- 170.
- 171.
- 172. Most developers have neverseen a domain model. They've only seen data models.
- 173.
- 174.
- 175.
- 176.
- 178.
- 179. I approved this 90k$ loan! Doyou approve this 100k$ loan?
- 180. … What do Ido with that now?!!
- 181. Answering a different questionis rude! (plus sync back the mutation is not so easy)
- 182. What if wejust reject with a suggestion to change the amount before re-submit?
- 183. In other words: ”SinglePath to Approval” Jez Humble and David Farley, “Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation”, Addison Wesley Professional, 2010
- 184. In other words: ”SinglePath to Approval”Production Jez Humble and David Farley, “Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation”, Addison Wesley Professional, 2010 Continuous Delivery
- 185. Loan Approval Loan Application System Credit Bureau Signatures Reject +suggest reduced amount Requests Approval 100k$ OK for 90k$ x Approved/ Rejected
- 186. No patch here! Fixthe source then commit as usual
- 187. No way! Itwould delay the process! Plus we don’t want to ask approvers to sign again! Business
- 188. OK. Still, perhaps we coulddo it anyway… Dev Team
- 189. OK for 100k$ ➜ afortiori OK for 90k$ ➜ ”A fortiori principle” No need to sign again!
- 190. Now we needto codify accurately what a fortiori means. That’s modeling the domain.
- 191. Not that hard: Lowerrisk -> a fortiori OK.
- 192. Domain Modeling means formingan opinion on how it behaves.
- 193. Programming as Theory- Building —Peter Naur (1985)
- 194. Anything can bean inspiration. Even Continuous Delivery patterns!
- 195.
- 196. Only rebuild whatneeds to be rebuilt after a change Given a set of source code files
- 197.
- 198.
- 199.
- 200. GNU Make hasan opinion on how to consider the problem.
- 201. Declare the dependencies. Letthe tool find out the workflow.
- 202.
- 203.
- 204. A breakthrough indomain modeling Why insist on using workflow engines everywhere?
- 205. Do you havean opinion on how to consider the business domain?
- 206. (Hint: ”We needEvent Sourcing” is probably not the best answer)
- 207. Which pattern? ”Propose severalmodels, choose one.” Design Spike. Try them.
- 208. Which pattern? from simpleto less simple.
- 209. Teaching Patterns to yourteam mates
- 210.
- 211.
- 212.
- 213. Show the benefits. Don’tpreach.
- 214. Own Internal Branding Youdon’t have to talk Flyweight or Monoid
- 215. The best codesample for training is your own code base. Embedded Learning
- 217. YOU DIDN’T SEE ALLTHESE PATTERNS BEFORE?
- 218.
- 219. No, you probably don’tneed this Event Sourcing here.
- 220. You probably should spendmore time Domain Model Technical Infrastructure HERE
- 221. Design is hard? Doit more often!
- 222. From Scratch? Lack ofdomain maturity makes everything look CRUD.
- 223.
- 224.
- 225. DCI by JimCoplien #DDDEU
- 226.
- 227.
- 228. Many patterns authors. Manypatterns. They converge, mostly. No need to learn them all.
- 229. Many patterns authors. Manypatterns. Still, learn more than one!
- 230. So many patternsoutside the Blue Book But do you really know all the patterns in the Blue Book?
- 232.
- 233. Follow me @cyriux Slides:slideshare.net/cyriux Blog: cyrille.martraire.com We offer training, coaching & consulting on DDD, BDD, TDD