Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

DDD patterns that were not in the book

3,483 views

Published on

We often relate Domain-Driven Design with the content of Eric Evans' book; however even this book suggests looking outside for other patterns and inspirations: analysis patterns (Accounting, Finance), domain-oriented use of design patterns (the Flyweight pattern), established formalisms (e.g. monoids) and XP literature in particular (e.g. the patterns on the c2 wiki and OOPSLA papers).

The world has not stopped since the book either, and new ideas keep on emerging regularly. And you can share your own patterns as well.

In this session, through examples and code we'll go through some particularly important patterns which deserve to be in your tool belt. We'll also provide guidance on how best to use them (or not), at the right time and in the right context, and on how to train your colleagues on them!

Published in: Software
  • Hello! Get Your Professional Job-Winning Resume Here - Check our website! https://vk.cc/818RFv
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

DDD patterns that were not in the book

  1. 1. @cyriux Cyrille Martraire DDDPatterns Beyond the Blue Book
  2. 2. Event Storming Event Sourcing CQRS DDD
  3. 3. What was before?
  4. 4. Is it useful?
  5. 5. Can I get better at DDD by looking at things outside of DDD?
  6. 6. This talk is the answer.
  7. 7. Passionate developer Deliberate Designer PARIS Since 1999 @cyriux Cyrille Martraire
  8. 8. Paris Software Craftsmanship Community since 2011 http://www.meetup.com/paris-software-craftsmanship/
  9. 9. arolla.fr @arollafr
  10. 10. arolla.fr @arollafr TDDBDDDDD
  11. 11. Software Development
  12. 12. Its history
  13. 13. Software Engineering
  14. 14. Tools, notations, MDA
  15. 15. 19 Vendor-sponsored conferences
  16. 16. Fortunately
  17. 17. Eric Evans - Domain-Driven Design
  18. 18. Should it be the only book to read to learn Domain- Driven Design? THE ONE & ONLY BOOK?
  19. 19. Any headline that ends in a question mark can be answered by no.
  20. 20. Eric Evans advocates in his book to look outside for more patterns & inspirations.
  21. 21. I did.
  22. 22. For this talk I have selected 43 patterns and I'm going to explain them one by one now.
  23. 23. <Facepalm>
  24. 24. OK.
  25. 25. "The best way to get the right answer on the Internet is not to ask a question, it's to post the wrong answer.” — Cunningham’s Law
  26. 26. Ward Cunningham WIKI XP CRC Cards
  27. 27. Ward Cunningham Patterns in software!
  28. 28. http://c2.com/ppr/checks.html DDD Inspiration
  29. 29. CHECKS Patterns 1. Whole Value 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
  30. 30. 25m + 10m = 35m (Custom Arithmetics) Whole Object with unit. Whole Object
  31. 31. Whole Object #NoPrimitive ”Because bits, strings and numbers can be used to represent almost anything, any one in isolation means almost nothing.”
  32. 32. Exceptional Value NaN Unde:ined NotApplicable 25m + NaN = NaN Don’t clutter your code with special case handing
  33. 33. going further…
  34. 34. Cashflow Sequence + Cashflow Sequence = Cashflow Sequence Monoid
  35. 35. Could we say that? HotelBooking Jan26to27 HotelBooking Jan27to29 HotelBooking Jan26to29 + = Monoid
  36. 36. Monoids Vector Spaces Cyclic Groups
  37. 37. Monoids advertisement brought to you by @cyriux!
  38. 38. 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
  39. 39. CHECKS Patterns 1. Whole Value 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
  40. 40. THE WORLD’s FIRST WIKI
  41. 41. PLoP98
  42. 42. Mind the biblio
  43. 43. In most domain models, most design patterns are technical noise. observer Singleton Factory Command VISITOR MEDIATOR Manager observer PROXY FACADE MEMENTO
  44. 44. But some design patterns also describe business domain concepts and relations.
  45. 45. Composite Interpreter Flyweight Strategy
  46. 46. observer Singleton Factory Command VISITOR MEDIATOR Manager observer PROXY FACADE MEMENTO Good-Old hint: ”Use pattern names in type names.”
  47. 47. In a domain model, avoid pattern names in types names.
  48. 48. DateAdjustmentStrategy Strategy
  49. 49. DateAdjustment DayShiftMethod EndOfMonthRule RoundingConvention CalculationMode Strategy
  50. 50. DateAdjustment DayShiftMethod EndOfMonthRule RoundingConvention CalculationMode Strategy Belongs to the Ubiquitous Language
  51. 51. ReimbursementPolicy EligibilityCriterion AcceptanceSpecification Strategy Belongs to the Ubiquitous Language
  52. 52. AccountingValuation NetPresentValueValuation LinearValuation BenchmarkBasedValuation AssetBasedValuation Strategy
  53. 53. AccountingValuations NetPresentValueValuation LinearValuation BenchmarkBasedValuation AssetBasedValuation Strategy Belongs to the Ubiquitous Language
  54. 54. AccountingValuations NetPresentValueValuation LinearValuation BenchmarkBasedValuation AssetBasedValuation Strategy No Noise
  55. 55. ValuationImpl Strategy
  56. 56. Strategy Pattern VAT VAT on net price Not Applicable Calculation + Null Object
  57. 57. Null Object. No, you should not replace every Null Object with Optional<T>
  58. 58. When to apply a pattern? (or not)
  59. 59. IF Statements vs. Strategy pattern? Naming-Driven Whichever reveals the business domain best
  60. 60. AccountingValuation NetPresentValueValuation LinearValuation BenchmarkBasedValuation AssetBasedValuation Strategy
  61. 61. DateAdjustmentStrategy Domain Patterns #NotInMyName
  62. 62. Annotate classes with custom annotations Stereotypes Annotations
  63. 63. Stereotypes Annotations Annotate classes with custom annotations
  64. 64. Domain type names are precious. They are for domain naming. Use annotations to document the stereotypes instead.
  65. 65. Stereotypes Annotations Annotate classes with custom annotations Embedded Learning
  66. 66. Stereotypes Annotations Annotate with custom annotations
  67. 67. Stereotypes Annotations Annotate with custom annotations
  68. 68. Stereotypes Annotations Annotate domain classes with custom annotations
  69. 69. Stereotypes Annotations Annotate domain classes with custom annotations
  70. 70. And learn on the job!
  71. 71. https://leanpub.com/livingdocumentation BUY MY BOOK! LIVING DOCUMENTATION
  72. 72. And now for more Object- Oriented Patterns
  73. 73. But Cyrille, Nobody does Object- Oriented anymore!
  74. 74. NOW WE DO FP! #NoPAttern
  75. 75. Evergreen SKILLS
  76. 76. Evergreen skills are worth learning
  77. 77. So now… Introducing the Flyweight pattern!
  78. 78. Flyweight Intent: Use sharing to support large numbers of [ine-grained objects ef[iciently
  79. 79. ”Hahaha. Nobody uses the Flyweight”
  80. 80. A matter of Compression = 3x
  81. 81. 503010 … Flyweight BUY SELL
  82. 82. 503010 … Flyweight We always want to make multiplicity manageable
  83. 83. 503010 … -503010 … Flyweight
  84. 84. -503010 … {10, 30, -50 …} Flyweight
  85. 85. {10, 30, -50 …} ∑ = -10 Flyweight
  86. 86. ∑ = -10 manageable = aggregable, comparable… Flyweight
  87. 87. Equity Trading: Standard Stock Multiple Trades of the same $10M - $30M - - $50M x
  88. 88. $10M IBM $30M IBM AXA $50M Derivative Trading: Multiple Contracts with a common structure
  89. 89. $10M IBM $30M IBM AXA $50M Derivative Trading: x
  90. 90. $10M IBM $30M IBM AXA $50M The essence of Flyweight x Many small, calculable elements One Blackbox IntrinsicExtrinsic
  91. 91. #WIN Flyweight
  92. 92. #WIN
  93. 93. This never works.
  94. 94. I see what you mean… BUT no way, IT DOES NOT WORK from a legal perspective!
  95. 95. FATAL OBJECTION
  96. 96. FATAL OBJECTION as hint of bounded Context!
  97. 97. Tip: Focus on one context = ≠ ≠
  98. 98. Works in this context only = ≠ ≠ Legal Money Management
  99. 99. It works in my context! = ≠ Transport Regulation Cargo Shipping
  100. 100. In what PERSPECTIVE could we say that? Bounded Context
  101. 101. Different Bounded Contexts, Different Patterns.
  102. 102. Different Patterns, Different Bounded Contexts.
  103. 103. #WorksInMyContext
  104. 104. HEY CYRILLE
  105. 105. WHY U SO FASCINATED with patterns?
  106. 106. Would you build Photoshop only with IF statements and FOR loops?
  107. 107. for (...) if (...) if (..) { for... } else else while
  108. 108. for (...) if (...) if (..) { for... } else else while
  109. 109. You should have a look at design patterns!
  110. 110. Strategy + State = EASY AGAIN!
  111. 111. Patterns ABUSE (Like every beginner)
  112. 112. Then I discovered Martin Fowler
  113. 113. Event Sourcing-ish
  114. 114. Retail Banking Medical Care
  115. 115. Traceability
  116. 116. Patterns illustrate deeper principles.
  117. 117. Traceability always points to the Past. (aka. Consequences depend on the Cause)
  118. 118. ORDER BASKET PAYMENT RETURN time refers torefers torefers to causality e-commerce
  119. 119. Study the patterns. Digest the principles. Apply to new domains.
  120. 120. CLAIM INSURANCE POLICY LOSS $ PAYMENT time refers torefers torefers to causality Insurance
  121. 121. Evergreen SKILLS
  122. 122. Different domains, same principle
  123. 123. Supple Domain Models Bespoke Code
  124. 124. Bespoke, Custom. OK. Reinventing the Wheel. NOT OK.
  125. 125. https://martinfowler.com/eaaDev/timeNarrative.html Temporal Property
  126. 126. https://martinfowler.com/eaaDev/timeNarrative.html Snapshot
  127. 127. https://martinfowler.com/eaaDev/timeNarrative.html Temporal Object
  128. 128. 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
  129. 129. 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?
  130. 130. https://martinfowler.com/eaaDev/timeNarrative.html Bi-temporal Time Time has two dimensions in software!
  131. 131. […] 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
  132. 132. […] 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
  133. 133. Excellent Design Teaching Material
  134. 134. Learn the history, not just the end state. Learning Steps (à la Event Sourcing)
  135. 135. Know the Holy Family :)
  136. 136. Illustrious Ancestors
  137. 137. Rebecca J. Wirfs-Brock First RDD paper in 1989!
  138. 138. http://tonyprusac.blogspot.fr/2015/11/deco2300-week-6.html CRC Cards
  139. 139. Event Storming Ancestor @mathiasverraes@ziobrando
  140. 140. MOAR ANALYSIS PATTERNS
  141. 141. TO DESIGN DOMAIN MODELS
  142. 142. Not just Code Also Ideas! Reuse all the things! And past insights
  143. 143. 164 A Business Transaction A quantity of something (e.g. cash) A quantity of something else
  144. 144. 165 A Business Transaction A quantity of something (e.g. cash) A quantity of something else Law: one side has to be cash
  145. 145. 166 A Business Transaction A quantity of something (e.g. cash) A quantity of something else Received Date Paid Date Trade Date
  146. 146. Congratulations! You can now reuse this domain insight!
  147. 147. WHY NOT WRITE YOUR OWN PATTERNS?
  148. 148. SO MANY ANALYSIS PATTERNS
  149. 149. TO DESIGN DOMAIN MODELS
  150. 150. Most developers have never seen a domain model. They've only seen data models.
  151. 151. WHAT’S A DOMAIN MODEL?
  152. 152. Let’s take an example
  153. 153. Loan Approval Loan Application System Credit Bureau Signatures Requests Approval 100k$ Approved/ Rejected
  154. 154. Loan Approval Loan Application System Credit Bureau Signatures Requests Approval 100k$ change to 90k$ Accept with in-place mutation :(
  155. 155. Do you approve this 100k$ loan?
  156. 156. I approved this 90k$ loan! Do you approve this 100k$ loan?
  157. 157. … What do I do with that now?!!
  158. 158. Answering a different question is rude! (plus sync back the mutation is not so easy)
  159. 159. What if we just reject with a suggestion to change the amount before re-submit?
  160. 160. In other words: ”Single Path to Approval” Jez Humble and David Farley, “Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation”, Addison Wesley Professional, 2010
  161. 161. In other words: ”Single Path 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
  162. 162. Loan Approval Loan Application System Credit Bureau Signatures Reject + suggest reduced amount Requests Approval 100k$ OK for 90k$ x Approved/ Rejected
  163. 163. No patch here! Fix the source then commit as usual
  164. 164. No way! It would delay the process! Plus we don’t want to ask approvers to sign again! Business
  165. 165. OK. Still, perhaps we could do it anyway… Dev Team
  166. 166. OK for 100k$ ➜ a fortiori OK for 90k$ ➜ ”A fortiori principle” No need to sign again!
  167. 167. Now we need to codify accurately what a fortiori means. That’s modeling the domain.
  168. 168. Not that hard: Lower risk -> a fortiori OK.
  169. 169. Domain Modeling means forming an opinion on how it behaves.
  170. 170. Programming as Theory- Building — Peter Naur (1985)
  171. 171. Anything can be an inspiration. Even Continuous Delivery patterns!
  172. 172. Let’s take another example
  173. 173. Only rebuild what needs to be rebuilt after a change Given a set of source code files
  174. 174. http://maemo.org/maemo_release_documentation/maemo4.1.x/node5.html
  175. 175. http://maemo.org/maemo_release_documentation/maemo4.1.x/node5.html
  176. 176. http://maemo.org/maemo_release_documentation/maemo4.1.x/node5.html Imagine doing that with a workflow engine?
  177. 177. GNU Make has an opinion on how to consider the problem.
  178. 178. Declare the dependencies. Let the tool find out the workflow.
  179. 179. http://maemo.org/maemo_release_documentation/maemo4.1.x/node5.html
  180. 180. http://maemo.org/maemo_release_documentation/maemo4.1.x/node5.html ReviewRisk check Legal check Management Review Management Review Product Launch R&D Done Sales Ready Marketing Campaign Product Specs Product Design
  181. 181. A breakthrough in domain modeling Why insist on using workflow engines everywhere?
  182. 182. Do you have an opinion on how to consider the business domain?
  183. 183. (Hint: ”We need Event Sourcing” is probably not the best answer)
  184. 184. Which pattern? ”Propose several models, choose one.” Design Spike. Try them.
  185. 185. Which pattern? from simple to less simple.
  186. 186. Teaching Patterns to your team mates
  187. 187. Mob-Programming @woodyzuill
  188. 188. https://www.industriallogic.com/blog/design-patterns-playing-cards/ Design Patterns Poker cards
  189. 189. Design Patterns Poker cards
  190. 190. Show the benefits. Don’t preach.
  191. 191. Own Internal Branding You don’t have to talk Flyweight or Monoid
  192. 192. The best code sample for training is your own code base. Embedded Learning
  193. 193. YOU DIDN’T SEE ALL THESE PATTERNS BEFORE?
  194. 194. You probably procrastinate on tech stuff.
  195. 195. No, you probably don’t need this Event Sourcing here.
  196. 196. You probably should spend more time Domain Model Technical Infrastructure HERE
  197. 197. Design is hard? Do it more often!
  198. 198. From Scratch? Lack of domain maturity makes everything look CRUD.
  199. 199. Mature Legacy Systems FTW!
  200. 200. NEW HORIZONS
  201. 201. DCI by Jim Coplien #DDDEU
  202. 202. https://blog.acolyer.org/ http://paperswelove.org/
  203. 203. In closing
  204. 204. Many patterns authors. Many patterns. They converge, mostly. No need to learn them all.
  205. 205. Many patterns authors. Many patterns. Still, learn more than one!
  206. 206. So many patterns outside the Blue Book But do you really know all the patterns in the Blue Book?
  207. 207. Merci ! h$p://cathy313.centerblog.net/539-bisounours
  208. 208. Follow me @cyriux Slides: slideshare.net/cyriux Blog: cyrille.martraire.com We offer training, coaching & consulting on DDD, BDD, TDD

×