Recommended
More Related Content
What's hot
What's hot (20)
Similar to DevDay2017 ESGI Essential DDD
Similar to DevDay2017 ESGI Essential DDD (20)
More from Gregory Boissinot
More from Gregory Boissinot (20)
Recently uploaded
Recently uploaded (20)
DevDay2017 ESGI Essential DDD
- 5. DDD
- 7. DDD IS AN APPROACH TO SOFTWARE DESIGN
- 8. DDD IS AN APPROACH TO SOFTWARE DESIGN FOR COMPLEX BUSINESS NEEDS
- 9. THE MOST SIGNIFICANT COMPLEXITY OF MANY APPLICATIONS IS NOT TECHNICAL
- 10. WE MUST FOCUS MORE ON THE BUSINESS CONCERNS
- 11. “Critical Complexity of most software projects is in understanding the domain itself “ Eric Evans
- 12. THE DOMAIN THE PROBLEM AREA The reality
- 13. THE DOMAIN IS A SPHERE OF KNOWLEDGE
- 14. THE DOMAIN IS A SET OF CONCEPTS EXPRESSING DISTILLED KNOWLEDGE
- 19. SOLVING COMPLEX PROBLEMS BY USING MODELS
- 20. A MODEL
- 22. A MODEL DESCRIBES THE OUTSIDE WORLD
- 23. A MODEL IS ABOUT USEFULNESS AROUND A SPECIFIC SET OF PROBLEMS
- 24. A MODEL IS ADAPTED TO AN USAGE
- 25. ABSTRACTION
- 26. ABSTRACTION IS TO FORGET THE NON SIGNIFICANT DETAILS
- 27. ABSTRACTION IS TO FORGET THE NON SIGNIFICANT DETAILS AND FOCUS ON THE ESSENTIALS
- 28. AN ABSTRACTION OF REALITY, NOT A REFLECTION OF REAL LIFE
- 30. PARIS METRO MAP
- 31. WRONG MODELS
- 32. WRONG MODELS CAUSE MASSIVE ACCIDENTAL COMPLEXITY
- 34. A MODEL CONTAINS ONLY WHAT IS RELEVANT
- 35. MODELS ARE NEITHER “RIGHT” OR “WRONG” BUT SOME ARE USEFUL THAN OTHERS
- 37. DESIGN IS THE ART OF TRADE-OFF
- 38. THE DOMAIN MODEL
- 39. THE DOMAIN MODEL IS AN ABSTRACTION OF THE PROBLEM DOMAIN
- 40. Domain Domain Model The reality An abstraction of reality designed to manage complexity for specific business cases A projection of the Real Domain THE PROBLEM SPACE THE SOLUTION SPACE
- 43. PRESSURE TO DELIVER SOFTWARE RELEASES ON A RELENTLESS SCHEDULE
- 44. LACK OF DESIGN
- 45. FOCUS ON SOLUTION SPACE Language Framework LibrariesInfra
- 48. UML JAVA / C# POOR SYNCHRONIZATION BETWEEN MODELS
- 52. WHAT DOES THE APPLICATION DO ? WHAT IS THE APPLICATION ABOUT ?
- 54. It works but no one knows how Initial software incarnation fast to produce time without care and consideration
- 56. MOST DEVELOPERS HAVE NEVER SEEN A DOMAIN MODEL
- 57. THEY’VE ONLY SEEN DATA MODELS
- 60. BIG BALL OF MUD
- 64. IMPROVE YOUR CRAFT AND INCREASE YOUR SUCCESS ON PROJECTS
- 65. CREATE BETTER SOFTWARE MORE EASILY
- 66. CREATE BETTER SOFTWARE MORE EASILY BY FOCUSING ON THE DOMAIN INSTEAD OF THE TECHNOLOGY
- 67. TO FOCUS ON BUSINESS VALUE
- 69. A TOOLSET : A COLLECTION OF PATTERNS, PRINCIPLES & PRACTICES
- 70. COLLABORATIVE MODELING STRATEGIC DESIGN (Context Mapping) TACTICAL DESIGN (Building Blocks, patterns) DDD BREAKDOWN
- 73. CREATING A USEFUL MODEL IS A COLLABORATIVE EXPERIENCE
- 75. MANY KNOWLEDGE CRUNCHING TECHNIQUES TO EXPLORE DOMAINS
- 76. MANY KNOWLEDGE CRUNCHING TECHNIQUES TO EXPLORE DOMAINS AND LEARN THE INTENT OF THE BUSINESS
- 77. KNOWLEDGE CRUNCHING IS THE ART OF DISTILLING RELEVANT INFORMATION
- 78. KNOWLEDGE CRUNCHING IS THE ART OF DISTILLING RELEVANT INFORMATION FROM THE PROBLEM DOMAIN
- 79. CLARIFYING QUESTIONS • What do you mean by … ? • What might lead someone to do / need .. ? • What else might happen ...?
- 80. THIS LEADS TO THE DISCOVERY OF IMPORTANT CONCEPTS
- 81. ALLOWS THE TEAM TO UNDERSTAND WHAT IS NOT IMPORTANT AND CAN BE EXCLUDED FROM THE MODEL
- 84. BUSINESS USERS CAN ALSO FIND TIRING AND DEEM IT UNPRODUCTIVE
- 85. MAKE YOUR KNOWLEDGE CRUNCHING SESSIONS FUN AND INTERACTIVE
- 87. INTRODUCE SOME FACILITATION GAMES AND OTHER FORMS OF REQUIREMENTS GATHERING TO ENGAGE YOUR AUDIENCE
- 88. EVENT STORMING
- 90. THE GOAL OF EVENT STORMING IS TO DISCOVER
- 91. THE GOAL OF EVENT STORMING IS TO DISCOVER NOT TO MAKE A DECISION
- 92. DRIVE KNOWLEDGE CRUNCHING AROUND THE MOST IMPORTANT USE CASE OF THE SYSTEM
- 96. DON’T STOP AT YOUR FIRST IDEA
- 97. YOU WON’T GET IT RIGHT THE FIRST TIME
- 98. GOOD DESIGN IS IMPERFECT DESIGN
- 99. THE ONLY WAY TO LEARN A COMPLEX SYSTEM IS TO LIVE AND TO INTERACT WITH IT
- 101. DON’T WAIT PERFECT TEAM
- 102. DON’T WAIT PERFECT TEAM DON’T WAIT PERFECT PEOPLE
- 103. USE BDD TO FOCUS ON THE BEHAVIOR OF THE APPLICATION AROUND CONCRETE SCENARIOS
- 104. UBIQUITOUS LANGUAGE
- 105. UBIQUITOUS LANGUAGE
- 106. VARIOUS EXPRESSIONS OF THE MODEL ARE BOUND BY THE SAME LANGUAGE
- 107. WHEN MODELING, EVERYONE SHOULD APPLY A SHARED LANGAGE RICH IN DOMAIN SPECIFIC TERMINOLOGY
- 111. BOUND BY LANGUAGE EXPRESSED AS DIAGRAMS EXPRESSED IN CONVERSATION EXPRESSED AS DOCUMENTATION EXPRESSED AS CODE THE DOMAIN MODEL
- 112. UML JAVA / C# Ubiquitous Language
- 113. UBIQUITOUS LANGUAGE IS A KEY TOOL
- 114. SUBDOMAINS
- 116. THE DOMAIN
- 126. SOLUTION SPACE
- 127. MOVE BUSINESS IN YOUR CODE
- 128. DDD IS A PROCESS THAT ALIGNS YOUR CODE WITH THE REALITY OF YOUR PROBLEM DOMAIN
- 130. THE CODE MODEL IS THE PRIMARY EXPRESSION OF THE DOMAIN MODEL
- 131. DDD ONLY REQUIRES THE MODEL TO BE KEPT ISOLATED FROM TECHNICAL COMPLEXITIES
- 133. public class GuaranteedOneYearDeliveryOffer { public void after(CarTireSold delivery) { if (delivery.TimeTimeTaken.Exceeded(oneYear) { sendCarBreakDiscountCouponTo(delivery.Customer) ; } } } Don’t focus on technical details … …talk in domain terns.
- 137. THE CODE AND THE DOMAIN MODEL ARE KEPT IN SYNERGY
- 138. THE CODE IS THE MODEL
- 139. THE CODE IS THE TRUTH
- 140. BOUNDED CONTEXT
- 141. DECOMPOSE THE SOLUTION SPACE FOR COMPLEX OR LARGE MODELS
- 142. DECOMPOSE THE SOLUTION SPACE AND DEVELOP MULTIPLE MODELS WITHIN EXPLICIT BOUNDARIES
- 144. CUSTOMER CONTEXT <<SALES>> Center of interest CONTEXT <<Accounting>> Method of payment CONTEXT <<Order Shippment>> Address Availability A SINGLE LARGE AMBIGUOUS MODEL BUSINESS USE CASE BUSINESS USE CASE BUSINESS USE CASE
- 145. CONTEXT MATTERS
- 146. CONTEXT <<SALES>> Customer: Center of interest CONTEXT <<ACCOUNTING>> Customer: Method of payment CONTEXT <<ORDER SHIPMENT>> Customer: Address Availability MULTIPLE SMALLER EXPLICIT MODELS
- 147. A BOUNDED CONTEXT
- 153. ALIGN BOUNDED CONTEXTS TO SUBDOMAINS Bounded ContextBounded Context Bounded Context Bounded Context
- 155. ARCHITECTURE STYLE
- 156. DDD DOESN’T DICTATE ANY SPECIAL ARCHITECTURAL PATTERNS
- 157. PATTERNS USED TO IMPLEMENT BOUNDED CONTEXTS SHOULD BE APPROPRIATE TO THE COMPLEXITY
- 158. MANY MODELS • Rich Domain Model • CRUD Model • Anemic Model • Transaction Script Model • etc
- 161. HEURISTICS
- 162. PRACTICAL METHOD NOT GUARANTEED TO BE OPTIMAL OR PERFECT
- 163. PRACTICAL METHOD NOT GUARANTEED TO BE OPTIMAL OR PERFECT BUT SUFFICIENT FOR IMMEDIATE GOALS
- 164. o Favorite Algorithms o Favorites Solutions o Favorites Approaches o Our Mental Models o Patterns o etc
- 165. DO NOT BE BLOCKED ON YOUR HEURISTICS • System Layers • ORM • IOC • Anemic Behaviours
- 167. INSIDE OUTSIDE
- 171. STRATEGIC DESIGN
- 172. COMPOSE BOUNDED CONTEXTS TO CREATE APPLICATIONS
- 173. USER INTERFACE APPLICATION BOUNDED CONTEXT A BOUNDED CONTEXT B BOUNDED CONTEXT C USER INTERFACE
- 176. INTEGRATION PATTERNS ENABLE BOUNDED CONTEXTS TO COMMUNICATE
- 177. TACTICAL PATTERNS • Value Objects • Entities • Aggregates • Repositories • Domain Services • Application Services • Domain Events
- 178. DDD IS NOT A PATTERN LANGUAGE
- 179. AGGREGATE
- 180. AGGREGATE IS A CLUSTER OF DOMAIN OBJECTS
- 181. AGGREGATE IS A CLUSTER OF DOMAIN OBJECTS THAT CAN BE TREATED AS A SINGLE UNIT
- 182. AGGREGATE IS A COLLECTION OF DATA THAT WE INTERACT WITH AS A UNIT
- 183. CONCLUSION
- 185. GO FURTHER