Beyond the Blue Book: 43 Patterns for Inspired DDD Modeling
•
35 likes•5,381 views
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!
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (15)
Similar to Beyond the Blue Book: 43 Patterns for Inspired DDD Modeling
Similar to Beyond the Blue Book: 43 Patterns for Inspired DDD Modeling (20)
More from Cyrille Martraire
More from Cyrille Martraire (17)
Recently uploaded
Recently uploaded (20)
Beyond the Blue Book: 43 Patterns for Inspired DDD Modeling
- 1. @cyriux Cyrille Martraire DDDPatterns Beyond the Blue Book
- 2. Event Storming Event Sourcing CQRS DDD
- 9. Passionate developer Deliberate Designer PARIS Since 1999 @cyriux Cyrille Martraire
- 10. Paris Software Craftsmanship Community since 2011 http://www.meetup.com/paris-software-craftsmanship/
- 16. Its history
- 20. Fortunately
- 21. Eric Evans - Domain-Driven Design
- 27. I did.
- 29. <Facepalm>
- 30. OK.
- 32. "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
- 36. 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
- 37. 25m + 10m = 35m (Custom Arithmetics) Whole Object with unit. Whole Object
- 40. going further…
- 41. Cashflow Sequence + Cashflow Sequence = Cashflow Sequence Monoid
- 42. Could we say that? HotelBooking Jan26to27 HotelBooking Jan27to29 HotelBooking Jan26to29 + = Monoid
- 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. 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
- 50. PLoP98
- 52. Mind the biblio
- 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 patterns also describe business domain concepts and relations.
- 57. observer Singleton Factory Command VISITOR MEDIATOR Manager observer PROXY FACADE MEMENTO Good-Old hint: ”Use pattern names in type names.”
- 58. In a domain model, avoid pattern names in types names.
- 62. ReimbursementPolicy EligibilityCriterion AcceptanceSpecification Strategy Belongs to the Ubiquitous Language
- 67. Strategy Pattern VAT VAT on net price Not Applicable Calculation + Null Object
- 68. Null Object. No, you should not replace every Null Object with Optional<T>
- 69. When to apply a pattern? (or not)
- 70. IF Statements vs. Strategy pattern? Naming-Driven Whichever reveals the business domain best
- 73. Annotate classes with custom annotations Stereotypes Annotations
- 74. Stereotypes Annotations Annotate classes with custom annotations
- 75. Domain type names are precious. They are for domain naming. Use annotations to document the stereotypes instead.
- 76. Stereotypes Annotations Annotate classes with custom annotations Embedded Learning
- 77. Stereotypes Annotations Annotate with custom annotations
- 78. Stereotypes Annotations Annotate with custom annotations
- 79. Stereotypes Annotations Annotate domain classes with custom annotations
- 80. Stereotypes Annotations Annotate domain classes with custom annotations
- 81. And learn on the job!
- 82. https://leanpub.com/livingdocumentation BUY MY BOOK! LIVING DOCUMENTATION
- 86. Evergreen SKILLS
- 91. A matter of Compression = 3x
- 93. 503010 … Flyweight We always want to make multiplicity manageable
- 95. -503010 … {10, 30, -50 …} Flyweight
- 96. {10, 30, -50 …} ∑ = -10 Flyweight
- 97. ∑ = -10 manageable = aggregable, comparable… Flyweight
- 98. Equity Trading: Standard Stock Multiple Trades of the same $10M - $30M - - $50M x
- 99. $10M IBM $30M IBM AXA $50M Derivative Trading: Multiple Contracts with a common structure
- 101. $10M IBM $30M IBM AXA $50M The essence of Flyweight x Many small, calculable elements One Blackbox IntrinsicExtrinsic
- 102. #WIN Flyweight
- 103. #WIN
- 104. This never works.
- 105. I see what you mean… BUT no way, IT DOES NOT WORK from a legal perspective!
- 108. FATAL OBJECTION
- 109. FATAL OBJECTION as hint of bounded Context!
- 110. Tip: Focus on one context = ≠ ≠
- 111. Works in this context only = ≠ ≠ Legal Money Management
- 112. It works in my context! = ≠ Transport Regulation Cargo Shipping
- 113. In what PERSPECTIVE could we say that? Bounded Context
- 116. #WorksInMyContext
- 117. HEY CYRILLE
- 118. WHY U SO FASCINATED with patterns?
- 119. Would you build Photoshop only 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 a look at design patterns!
- 129. Event Sourcing-ish
- 132. Traceability
- 134. Traceability always points to the Past. (aka. Consequences depend on the Cause)
- 135. ORDER BASKET PAYMENT RETURN time refers torefers torefers to causality e-commerce
- 136. Study the patterns. Digest the principles. Apply to new domains.
- 138. CLAIM INSURANCE POLICY LOSS $ PAYMENT time refers torefers torefers to causality Insurance
- 139. Evergreen SKILLS
- 142. Bespoke, Custom. OK. Reinventing the Wheel. NOT OK.
- 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 has two dimensions in software!
- 151. […] 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
- 152. […] 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
- 154. Learn the history, not just the end state. Learning Steps (à la Event Sourcing)
- 155. Know the Holy Family :)
- 157. Rebecca J. Wirfs-Brock First RDD paper in 1989!
- 163. Not just Code Also Ideas! Reuse all the things! And past insights
- 164. 164 A Business Transaction A quantity of something (e.g. cash) A quantity of something else
- 165. 165 A Business Transaction A quantity of something (e.g. cash) A quantity of something else Law: one side has to be cash
- 166. 166 A Business Transaction A quantity of something (e.g. cash) A quantity of something else Received Date Paid Date Trade Date
- 167. Congratulations! You can now reuse this domain insight!
- 168. WHY NOT WRITE YOUR OWN PATTERNS?
- 172. Most developers have never seen a domain model. They've only seen data models.
- 176. Loan Approval Loan Application System Credit Bureau Signatures Requests Approval 100k$ change to 90k$ Accept with in-place mutation :(
- 179. I approved this 90k$ loan! Do you approve this 100k$ loan?
- 180. … What do I do with that now?!!
- 181. Answering a different question is rude! (plus sync back the mutation is not so easy)
- 182. What if we just reject with a suggestion to change the amount before re-submit?
- 183. 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
- 184. 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
- 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! Fix the source then commit as usual
- 187. No way! It would delay the process! Plus we don’t want to ask approvers to sign again! Business
- 188. OK. Still, perhaps we could do it anyway… Dev Team
- 189. OK for 100k$ ➜ a fortiori OK for 90k$ ➜ ”A fortiori principle” No need to sign again!
- 190. Now we need to codify accurately what a fortiori means. That’s modeling the domain.
- 191. Not that hard: Lower risk -> a fortiori OK.
- 192. Domain Modeling means forming an opinion on how it behaves.
- 193. Programming as Theory- Building — Peter Naur (1985)
- 194. Anything can be an inspiration. Even Continuous Delivery patterns!
- 196. Only rebuild what needs to be rebuilt after a change Given a set of source code files
- 199. http://maemo.org/maemo_release_documentation/maemo4.1.x/node5.html Imagine doing that with a workflow engine?
- 200. GNU Make has an opinion on how to consider the problem.
- 201. Declare the dependencies. Let the tool find out the workflow.
- 204. A breakthrough in domain modeling Why insist on using workflow engines everywhere?
- 205. Do you have an opinion on how to consider the business domain?
- 206. (Hint: ”We need Event Sourcing” is probably not the best answer)
- 207. Which pattern? ”Propose several models, choose one.” Design Spike. Try them.
- 208. Which pattern? from simple to less simple.
- 209. Teaching Patterns to your team mates
- 211. https://www.industriallogic.com/blog/design-patterns-playing-cards/ Design Patterns Poker cards
- 212. Design Patterns Poker cards
- 213. Show the benefits. Don’t preach.
- 214. Own Internal Branding You don’t have to talk Flyweight or Monoid
- 215. The best code sample for training is your own code base. Embedded Learning
- 217. YOU DIDN’T SEE ALL THESE PATTERNS BEFORE?
- 218. You probably procrastinate on tech stuff.
- 219. No, you probably don’t need this Event Sourcing here.
- 220. You probably should spend more time Domain Model Technical Infrastructure HERE
- 221. Design is hard? Do it more often!
- 222. From Scratch? Lack of domain maturity makes everything look CRUD.
- 224. NEW HORIZONS
- 225. DCI by Jim Coplien #DDDEU
- 227. In closing
- 228. Many patterns authors. Many patterns. They converge, mostly. No need to learn them all.
- 229. Many patterns authors. Many patterns. Still, learn more than one!
- 230. So many patterns outside the Blue Book But do you really know all the patterns in the Blue Book?
- 233. Follow me @cyriux Slides: slideshare.net/cyriux Blog: cyrille.martraire.com We offer training, coaching & consulting on DDD, BDD, TDD