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.
Domain-Driven Design For Real Cyrille Martraire @cyriux
1968
Banker & Programmer
”In 1968 DDD was a tautology” David West, DDD Europe 2017
NATO Software Engineering Conference 1968
business analyst software developer
DDDBusiness Expertise Software Expertise
Passionate developer PARIS Since 1999 @cyriux Cyrille Martraire
Paris Software Craftsmanship Community http://www.meetup.com/paris-software-craftsmanship/
TDD BDD DDD Legacy
DDD?
h"p://www.virtual-genius.com/blog/post/Domain-Driven-Design-Immersion-Course-e28093-Part-5.aspx
Seniors Developers h"p://www.thisisio.ie/blog/arDcle/149/hiring_senior_developer
OFTENMISTAKEN No Tool Needed CQRS: most popular WELL-respected
My DDD Map 21 Modeling == Code Strategic Design Bounded Context Context Mapping CQRS / EC large-scale structures Tactical ...
DDD Map 22 Modeling == Code Strategic Design Bounded Context Context Mapping CQRS / EC large-scale structures Tactical Des...
DDD Essentials Curious about the domain Talking the Domain Language Focus on Core Domain Modeling == Code Strategic Design...
Example PLZ!
Domain Expert
Please add a discount code to the purchase!
You mean the shopping cart?
Yes, this is what I meant (of course)
Ok, so let’s add a voucher field to the class ”BasketModel”
Purchase Shopping Cart BasketModel 32
problem Systematic Translation (waste of time + confusion as-a-service)
solution Ubiquitous Language talk the domain language
Ubiquitous Language • Naming •Searchable •Easy to pronounce •No abbreviation • Definitions •Shared definition •Understand,...
Everyone talking the Domain Language Everywhere (even in the code) 37
Everyone talking the Domain Language Everywhere (even in the code) 38
Everyone talking the Domain Language Everywhere (even in the code) 39
90% Business Domain Language here
Extract a word cloud from your code BAD
Extract a word cloud from your code Better
null DDD style of code? • No technical pollu5on • Spring, Hibernate, logger • javax.* • SQL
[Object Calisthenics] 1. Wrap all primitives and strings 2. Use only one dot per line 3. Don’t abbreviate 4. Keep all clas...
45 Tactical Patterns Value Objects Entities Domain Services Domain Events Repositories
Ubiquitous Language everywhere 47
So you mean DDD is primarily just talking business domain? 48
Ubiquitous Language everywhere 50 @cyriux
https://leanpub.com/livingdocumentation BUY MY BOOK!
When to apply DDD? 52
WeWant:
WeWant: Anapptodetect paymentfrauds
Rich business domain 55 Risk is in the domain
Apply DDD! 56
WeWant: Afeaturetobeatour competition
Differentiating business domain 58 Value is in the domain
Apply DDD! 59
WeWant: AnotherTODOlistapp
Go CRUD! 61
Focus on the Core Domain 62
Differentiating to the business?
Apply DDD! 64
Not differentiating?
BUY
Domain Curiosity 67
I only care about Kubernetes
Hey! Finance is cool!
Oh, this domain is really cool!
Oh, this domain is really cool! I’d like to know it better!
Start with Examples 74
Scenarios Intent
Scenarios Concrete examples
BDD: probably your best friend to start DDD
@cyriux
Modeling == Code 79
Example PLZ!
Please add a new discount mode
Where do I add that?
I know: I’ll add the code in the MainController class!
MainController 28 fields here … 245 methods here … 6422 lines
problem Code Gravity big stuff attracts even more stuff and gets bigger @carlopescio
solution Domain Modeling business domain as code, literally
Payment … Discounting … Add the feature only here
Refactor based on your domain understanding 89
Domain-Driven Refactoring 90
Domain modeling in practice 91
*NOT* UML/MDA! h"p://depinfo.u-cergy.fr/projets/close2u/fr/tag/uml/
Kitten kitty = new Kitten(Attitude.ROCK_STAR); Microphone mike = new Microphone(); kitty.sing(mike); system.out.println(mi...
Good modeling? 96
Learn the business domain by reading the code 97
Learn the business domain by reading the code 98 and running the code
We want IT alignment blabla…
We want IT alignment blabla…
I know how to do that! Once you know DDD…
Functional Area | Code Module 103 1-to-1
Example PLZ!
105 decision making vehicle dispatching cyclic dependency!
106 decision making vehicle dispatching cyclic dependency!
107 decision making vehicle dispatching Which one to cut?
A business domain Decision 108
109 decision making vehicle dispatching 1 business decision
110 decision making vehicle dispatching technical impact
Strategic Design 113
Bounded Contexts Explicitly define the context within which a model applies. Explicitly set boundaries in terms of team org...
Bounded Contexts Explicitly define the context within which a model applies. Explicitly set boundaries in terms of team org...
Customer addressLine zipcode city …
Hey! Companies have a different billing address!
I know: let’s add it with a flag!
Purchase addressLine zipcode city has2AddressesFlag addressLine2 zipcode2 city2
Customer addressLine zipcode city has2AddressesFlag addressLine2 zipcode2 city2 If (! has2AddressesFlag) billing address l...
Customer addressLine zipcode city has2AddressesFlag addressLine2 zipcode2 city2 If (! has2AddressesFlag) billing address l...
problem Code Mess by lack of domain understanding
solution Bounded Contexts split 1 big model by sub-domains
Split by business domains 125
Customer addressLine zipcode city date amount user Account addressLine zipcode city Recipient + + Shipping BillingShopping...
Shipping BillingShopping Cart
Shipping BillingShopping Cart Bounded Contexts by domain
Customer addressLine zipcode city date amount user Account addressLine zipcode city Recipient + + New names
customer ≠ account ≠ recipient 130 Near Synonyms
Customer addressLine zipcode city date amount user Account addressLine zipcode city Recipient + + Suggest Contexts
Customer addressLine zipcode city date amount user Account addressLine zipcode city Recipient + + Default value: billing a...
But… that’s massive duplication!
”No Duplication” means ”Coupling”
Evolve differently in the long term 135
addressLine zipcode city Account Billing addressLine zipcode city Recipient Shipping
addressLine zipcode city contactName taxRegion Account Billing addressLine zipcode city Recipient Shipping
addressLine zipcode city contactName taxRegion Account Billing addressLine zipcode city doorCode availabilityTimeSlots Rec...
Purchase BillingUnit DeliveryRequest * * e.g. marketplace
DRY == Coupling Bounded Contexts: We decide to reduce coupling at the cost of some redundancy 140
What a book at Amazon? •Catalog: Picture, title, authors, rating, format (ebook or paper), category •Recommandation: List ...
Different perspectives My book is not your book
colleague committer collaborator candidate friend peer
Polyglot persistence (random examples) •Catalog: NoSQL •Recommandation: Batch + GraphDB •Shipping: RDBMS •Shopping cart: R...
Team organization •Catalog: Team 1 •Recommandation: Team 2 •Shipping: Team 3 •Shopping cart: Team 4 •Customer review: Team...
by the way...
loosely-coupled, service-oriented architecture with bounded context.
loosely-coupled, service-oriented architecture with bounded context. Adrian Cockcroft Microservices!
DDD?
Identification au code Identification au métier
DDD Framework?
DDD Framework?
What language?
What language? Does not matter (but easier with F#)
Is DDD for you? • Do you feel close to XP? • Do you love distributed caches?
How to go further? Read the blue book Read Martin Fowler Try Event Storming
h"p://cathy313.centerblog.net/539-bisounours @cyriux
DDD for real
DDD for real
DDD for real
DDD for real
DDD for real
DDD for real
DDD for real
DDD for real
DDD for real
DDD for real
DDD for real
DDD for real
DDD for real
DDD for real
DDD for real
DDD for real
DDD for real
DDD for real
DDD for real
DDD for real
DDD for real
DDD for real
DDD for real
DDD for real
Upcoming SlideShare
Loading in …5
×

DDD for real

1,396 views

Published on

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!

Published in: Technology
License: CC Attribution-NonCommercial License
no profile picture user

  • Login to see the comments

Show More

DDD for real

  1. 1. Domain-Driven Design For Real Cyrille Martraire @cyriux
  2. 2. 1968
  3. 3. Banker & Programmer
  4. 4. ”In 1968 DDD was a tautology” David West, DDD Europe 2017
  5. 5. NATO Software Engineering Conference 1968
  6. 6. business analyst software developer
  7. 7. DDDBusiness Expertise Software Expertise
  8. 8. Passionate developer PARIS Since 1999 @cyriux Cyrille Martraire
  9. 9. Paris Software Craftsmanship Community http://www.meetup.com/paris-software-craftsmanship/
  10. 10. TDD BDD DDD Legacy
  11. 11. DDD?
  12. 12. h"p://www.virtual-genius.com/blog/post/Domain-Driven-Design-Immersion-Course-e28093-Part-5.aspx
  13. 13. Seniors Developers h"p://www.thisisio.ie/blog/arDcle/149/hiring_senior_developer
  14. 14. OFTENMISTAKEN No Tool Needed CQRS: most popular WELL-respected
  15. 15. My DDD Map 21 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
  16. 16. DDD Map 22 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
  17. 17. DDD Essentials Curious about the domain Talking the Domain Language Focus on Core Domain Modeling == Code Strategic Design (+ techniques to achieve that) 24
  18. 18. Example PLZ!
  19. 19. Domain Expert
  20. 20. Please add a discount code to the purchase!
  21. 21. You mean the shopping cart?
  22. 22. Yes, this is what I meant (of course)
  23. 23. Ok, so let’s add a voucher field to the class ”BasketModel”
  24. 24. Purchase Shopping Cart BasketModel 32
  25. 25. problem Systematic Translation (waste of time + confusion as-a-service)
  26. 26. solution Ubiquitous Language talk the domain language
  27. 27. Ubiquitous Language • Naming •Searchable •Easy to pronounce •No abbreviation • Definitions •Shared definition •Understand, not just a vocabulary
  28. 28. Everyone talking the Domain Language Everywhere (even in the code) 37
  29. 29. Everyone talking the Domain Language Everywhere (even in the code) 38
  30. 30. Everyone talking the Domain Language Everywhere (even in the code) 39
  31. 31. 90% Business Domain Language here
  32. 32. Extract a word cloud from your code BAD
  33. 33. Extract a word cloud from your code Better
  34. 34. null DDD style of code? • No technical pollu5on • Spring, Hibernate, logger • javax.* • SQL
  35. 35. [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
  36. 36. 45 Tactical Patterns Value Objects Entities Domain Services Domain Events Repositories
  37. 37. Ubiquitous Language everywhere 47
  38. 38. So you mean DDD is primarily just talking business domain? 48
  39. 39. Ubiquitous Language everywhere 50 @cyriux
  40. 40. https://leanpub.com/livingdocumentation BUY MY BOOK!
  41. 41. When to apply DDD? 52
  42. 42. WeWant:
  43. 43. WeWant: Anapptodetect paymentfrauds
  44. 44. Rich business domain 55 Risk is in the domain
  45. 45. Apply DDD! 56
  46. 46. WeWant: Afeaturetobeatour competition
  47. 47. Differentiating business domain 58 Value is in the domain
  48. 48. Apply DDD! 59
  49. 49. WeWant: AnotherTODOlistapp
  50. 50. Go CRUD! 61
  51. 51. Focus on the Core Domain 62
  52. 52. Differentiating to the business?
  53. 53. Apply DDD! 64
  54. 54. Not differentiating?
  55. 55. BUY
  56. 56. Domain Curiosity 67
  57. 57. I only care about Kubernetes
  58. 58. Hey! Finance is cool!
  59. 59. Oh, this domain is really cool!
  60. 60. Oh, this domain is really cool! I’d like to know it better!
  61. 61. Start with Examples 74
  62. 62. Scenarios Intent
  63. 63. Scenarios Concrete examples
  64. 64. BDD: probably your best friend to start DDD
  65. 65. @cyriux
  66. 66. Modeling == Code 79
  67. 67. Example PLZ!
  68. 68. Please add a new discount mode
  69. 69. Where do I add that?
  70. 70. I know: I’ll add the code in the MainController class!
  71. 71. MainController 28 fields here … 245 methods here … 6422 lines
  72. 72. problem Code Gravity big stuff attracts even more stuff and gets bigger @carlopescio
  73. 73. solution Domain Modeling business domain as code, literally
  74. 74. Payment … Discounting … Add the feature only here
  75. 75. Refactor based on your domain understanding 89
  76. 76. Domain-Driven Refactoring 90
  77. 77. Domain modeling in practice 91
  78. 78. *NOT* UML/MDA! h"p://depinfo.u-cergy.fr/projets/close2u/fr/tag/uml/
  79. 79. Kitten kitty = new Kitten(Attitude.ROCK_STAR); Microphone mike = new Microphone(); kitty.sing(mike); system.out.println(mike.playBack()); //”mew mew meeew”
  80. 80. Good modeling? 96
  81. 81. Learn the business domain by reading the code 97
  82. 82. Learn the business domain by reading the code 98 and running the code
  83. 83. We want IT alignment blabla…
  84. 84. We want IT alignment blabla…
  85. 85. I know how to do that! Once you know DDD…
  86. 86. Functional Area | Code Module 103 1-to-1
  87. 87. Example PLZ!
  88. 88. 105 decision making vehicle dispatching cyclic dependency!
  89. 89. 106 decision making vehicle dispatching cyclic dependency!
  90. 90. 107 decision making vehicle dispatching Which one to cut?
  91. 91. A business domain Decision 108
  92. 92. 109 decision making vehicle dispatching 1 business decision
  93. 93. 110 decision making vehicle dispatching technical impact
  94. 94. Strategic Design 113
  95. 95. 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.
  96. 96. 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!
  97. 97. Customer addressLine zipcode city …
  98. 98. Hey! Companies have a different billing address!
  99. 99. I know: let’s add it with a flag!
  100. 100. Purchase addressLine zipcode city has2AddressesFlag addressLine2 zipcode2 city2
  101. 101. 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 =
  102. 102. 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
  103. 103. problem Code Mess by lack of domain understanding
  104. 104. solution Bounded Contexts split 1 big model by sub-domains
  105. 105. Split by business domains 125
  106. 106. Customer addressLine zipcode city date amount user Account addressLine zipcode city Recipient + + Shipping BillingShopping Cart
  107. 107. Shipping BillingShopping Cart
  108. 108. Shipping BillingShopping Cart Bounded Contexts by domain
  109. 109. Customer addressLine zipcode city date amount user Account addressLine zipcode city Recipient + + New names
  110. 110. customer ≠ account ≠ recipient 130 Near Synonyms
  111. 111. Customer addressLine zipcode city date amount user Account addressLine zipcode city Recipient + + Suggest Contexts
  112. 112. Customer addressLine zipcode city date amount user Account addressLine zipcode city Recipient + + Default value: billing address = shipping address
  113. 113. But… that’s massive duplication!
  114. 114. ”No Duplication” means ”Coupling”
  115. 115. Evolve differently in the long term 135
  116. 116. addressLine zipcode city Account Billing addressLine zipcode city Recipient Shipping
  117. 117. addressLine zipcode city contactName taxRegion Account Billing addressLine zipcode city Recipient Shipping
  118. 118. addressLine zipcode city contactName taxRegion Account Billing addressLine zipcode city doorCode availabilityTimeSlots Recipient Shipping
  119. 119. Purchase BillingUnit DeliveryRequest * * e.g. marketplace
  120. 120. DRY == Coupling Bounded Contexts: We decide to reduce coupling at the cost of some redundancy 140
  121. 121. What 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
  122. 122. Different perspectives My book is not your book
  123. 123. colleague committer collaborator candidate friend peer
  124. 124. 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
  125. 125. 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
  126. 126. by the way...
  127. 127. loosely-coupled, service-oriented architecture with bounded context.
  128. 128. loosely-coupled, service-oriented architecture with bounded context. Adrian Cockcroft Microservices!
  129. 129. DDD?
  130. 130. Identification au code Identification au métier
  131. 131. DDD Framework?
  132. 132. DDD Framework?
  133. 133. What language?
  134. 134. What language? Does not matter (but easier with F#)
  135. 135. Is DDD for you? • Do you feel close to XP? • Do you love distributed caches?
  136. 136. How to go further? Read the blue book Read Martin Fowler Try Event Storming
  137. 137. h"p://cathy313.centerblog.net/539-bisounours @cyriux

×