More Related Content
Similar to DevDay2017 ESGI Essential DDD
DevDay2017 ESGI Essential DDD
- 1.
- 2.
- 3.
- 5.
- 6.
- 7. DDD IS AN APPROACH TOSOFTWARE DESIGN
- 8. DDD IS AN APPROACH TOSOFTWARE DESIGN FOR COMPLEX BUSINESS NEEDS
- 9. THE MOST SIGNIFICANT COMPLEXITY OFMANY APPLICATIONS IS NOT TECHNICAL
- 10. WE MUST FOCUS MOREON THE BUSINESS CONCERNS
- 11. “Critical Complexity ofmost software projects is in understanding the domain itself “ Eric Evans
- 12.
- 13. THE DOMAIN IS A SPHEREOF KNOWLEDGE
- 14. THE DOMAIN IS ASET OF CONCEPTS EXPRESSING DISTILLED KNOWLEDGE
- 15.
- 16.
- 17.
- 18.
- 19. SOLVING COMPLEX PROBLEMS BYUSING MODELS
- 20.
- 21.
- 22.
- 23. A MODEL IS ABOUTUSEFULNESS AROUND A SPECIFIC SET OF PROBLEMS
- 24. A MODEL IS ADAPTED TOAN USAGE
- 25.
- 26. ABSTRACTION IS TO FORGETTHE NON SIGNIFICANT DETAILS
- 27. ABSTRACTION IS TO FORGETTHE NON SIGNIFICANT DETAILS AND FOCUS ON THE ESSENTIALS
- 28. AN ABSTRACTION OF REALITY, NOTA REFLECTION OF REAL LIFE
- 29.
- 30.
- 31.
- 32. WRONG MODELS CAUSE MASSIVE ACCIDENTALCOMPLEXITY
- 33.
- 34. A MODEL CONTAINS ONLY WHATIS RELEVANT
- 35. MODELS ARE NEITHER “RIGHT”OR “WRONG” BUT SOME ARE USEFUL THAN OTHERS
- 36.
- 37. DESIGN IS THE ARTOF TRADE-OFF
- 38.
- 39. THE DOMAIN MODEL ISAN ABSTRACTION OF THE PROBLEM DOMAIN
- 40. Domain Domain Model The reality Anabstraction of reality designed to manage complexity for specific business cases A projection of the Real Domain THE PROBLEM SPACE THE SOLUTION SPACE
- 41.
- 42.
- 43. PRESSURE TO DELIVER SOFTWARERELEASES ON A RELENTLESS SCHEDULE
- 44.
- 45. FOCUS ON SOLUTIONSPACE Language Framework LibrariesInfra
- 46.
- 47.
- 48. UML JAVA /C# POOR SYNCHRONIZATION BETWEEN MODELS
- 49.
- 51.
- 52. WHAT DOES THE APPLICATION DO? WHAT IS THE APPLICATION ABOUT ?
- 53.
- 54. It works butno one knows how Initial software incarnation fast to produce time without care and consideration
- 55.
- 56. MOST DEVELOPERS HAVE NEVERSEEN A DOMAIN MODEL
- 57. THEY’VE ONLY SEEN DATAMODELS
- 58.
- 60. BIG BALL OFMUD
- 63.
- 64. IMPROVE YOUR CRAFT ANDINCREASE YOUR SUCCESS ON PROJECTS
- 65.
- 66. CREATE BETTER SOFTWARE MOREEASILY BY FOCUSING ON THE DOMAIN INSTEAD OF THE TECHNOLOGY
- 67. TO FOCUS ON BUSINESSVALUE
- 68.
- 69. A TOOLSET :A COLLECTION OF PATTERNS, PRINCIPLES & PRACTICES
- 70.
- 71.
- 72.
- 73. CREATING A USEFUL MODEL ISA COLLABORATIVE EXPERIENCE
- 74.
- 75.
- 76. MANY KNOWLEDGE CRUNCHING TECHNIQUES TO EXPLOREDOMAINS AND LEARN THE INTENT OF THE BUSINESS
- 77. KNOWLEDGE CRUNCHING IS THEART OF DISTILLING RELEVANT INFORMATION
- 78. KNOWLEDGE CRUNCHING IS THEART OF DISTILLING RELEVANT INFORMATION FROM THE PROBLEM DOMAIN
- 79. CLARIFYING QUESTIONS • Whatdo you mean by … ? • What might lead someone to do / need .. ? • What else might happen ...?
- 80. THIS LEADS TO THEDISCOVERY OF IMPORTANT CONCEPTS
- 81. ALLOWS THE TEAMTO UNDERSTAND WHAT IS NOT IMPORTANT AND CAN BE EXCLUDED FROM THE MODEL
- 82.
- 83.
- 84. BUSINESS USERS CAN ALSOFIND TIRING AND DEEM IT UNPRODUCTIVE
- 85. MAKE YOUR KNOWLEDGE CRUNCHING SESSIONS FUNAND INTERACTIVE
- 86.
- 87. INTRODUCE SOME FACILITATION GAMES ANDOTHER FORMS OF REQUIREMENTS GATHERING TO ENGAGE YOUR AUDIENCE
- 88.
- 89.
- 90. THE GOAL OF EVENTSTORMING IS TO DISCOVER
- 91. THE GOAL OF EVENTSTORMING IS TO DISCOVER NOT TO MAKE A DECISION
- 92. DRIVE KNOWLEDGE CRUNCHING AROUND THEMOST IMPORTANT USE CASE OF THE SYSTEM
- 93.
- 94.
- 95.
- 96.
- 97. YOU WON’T GETIT RIGHT THE FIRST TIME
- 98. GOOD DESIGN IS IMPERFECTDESIGN
- 99. THE ONLY WAY TOLEARN A COMPLEX SYSTEM IS TO LIVE AND TO INTERACT WITH IT
- 100.
- 101.
- 102. DON’T WAIT PERFECTTEAM DON’T WAIT PERFECT PEOPLE
- 103. USE BDD TO FOCUSON THE BEHAVIOR OF THE APPLICATION AROUND CONCRETE SCENARIOS
- 104.
- 105.
- 106. VARIOUS EXPRESSIONS OF THEMODEL ARE BOUND BY THE SAME LANGUAGE
- 107. WHEN MODELING, EVERYONE SHOULDAPPLY A SHARED LANGAGE RICH IN DOMAIN SPECIFIC TERMINOLOGY
- 108.
- 109.
- 110.
- 111. BOUND BY LANGUAGE EXPRESSED AS DIAGRAMS EXPRESSEDIN CONVERSATION EXPRESSED AS DOCUMENTATION EXPRESSED AS CODE THE DOMAIN MODEL
- 112. UML JAVA /C# Ubiquitous Language
- 113. UBIQUITOUS LANGUAGE IS AKEY TOOL
- 114.
- 115.
- 116.
- 118.
- 120.
- 121.
- 122.
- 123.
- 125.
- 126.
- 127.
- 128. DDD IS APROCESS THAT ALIGNS YOUR CODE WITH THE REALITY OF YOUR PROBLEM DOMAIN
- 129.
- 130. THE CODE MODELIS THE PRIMARY EXPRESSION OF THE DOMAIN MODEL
- 131. DDD ONLY REQUIRES THE MODEL TOBE KEPT ISOLATED FROM TECHNICAL COMPLEXITIES
- 132.
- 133. public class GuaranteedOneYearDeliveryOffer { publicvoid after(CarTireSold delivery) { if (delivery.TimeTimeTaken.Exceeded(oneYear) { sendCarBreakDiscountCouponTo(delivery.Customer) ; } } } Don’t focus on technical details … …talk in domain terns.
- 134.
- 137. THE CODE AND THEDOMAIN MODEL ARE KEPT IN SYNERGY
- 138. THE CODE IS THEMODEL
- 139. THE CODE IS THETRUTH
- 140.
- 141. DECOMPOSE THE SOLUTION SPACE FORCOMPLEX OR LARGE MODELS
- 142. DECOMPOSE THE SOLUTION SPACE ANDDEVELOP MULTIPLE MODELS WITHIN EXPLICIT BOUNDARIES
- 144. CUSTOMER CONTEXT <<SALES>> Center of interest CONTEXT <<Accounting>> Method of payment CONTEXT <<Order Shippment>> Address Availability A SINGLE LARGEAMBIGUOUS MODEL BUSINESS USE CASE BUSINESS USE CASE BUSINESS USE CASE
- 145.
- 146. CONTEXT <<SALES>> Customer: Center of interest CONTEXT <<ACCOUNTING>> Customer:Method of payment CONTEXT <<ORDER SHIPMENT>> Customer: Address Availability MULTIPLE SMALLER EXPLICIT MODELS
- 147.
- 148.
- 149.
- 150.
- 151.
- 152.
- 153.
- 154.
- 155.
- 156.
- 157. PATTERNS USED TO IMPLEMENT BOUNDEDCONTEXTS SHOULD BE APPROPRIATE TO THE COMPLEXITY
- 158. MANY MODELS • RichDomain Model • CRUD Model • Anemic Model • Transaction Script Model • etc
- 159.
- 160.
- 161.
- 162. PRACTICAL METHOD NOT GUARANTEEDTO BE OPTIMAL OR PERFECT
- 163. PRACTICAL METHOD NOT GUARANTEEDTO BE OPTIMAL OR PERFECT BUT SUFFICIENT FOR IMMEDIATE GOALS
- 164. o Favorite Algorithms o Favorites Solutions oFavorites Approaches o Our Mental Models o Patterns o etc
- 165. DO NOT BEBLOCKED ON YOUR HEURISTICS • System Layers • ORM • IOC • Anemic Behaviours
- 166.
- 167.
- 168.
- 169.
- 170.
- 171.
- 172. COMPOSE BOUNDED CONTEXTS TO CREATEAPPLICATIONS
- 173.
- 175.
- 176.
- 177. TACTICAL PATTERNS • ValueObjects • Entities • Aggregates • Repositories • Domain Services • Application Services • Domain Events
- 178. DDD IS NOT A PATTERNLANGUAGE
- 179.
- 180. AGGREGATE IS A CLUSTEROF DOMAIN OBJECTS
- 181. AGGREGATE IS A CLUSTEROF DOMAIN OBJECTS THAT CAN BE TREATED AS A SINGLE UNIT
- 182. AGGREGATE IS A COLLECTIONOF DATA THAT WE INTERACT WITH AS A UNIT
- 183.
- 184.
- 185.