SOAT Agile Day 2017 DDD
- 1. Thinking in DDD Grégory BOISSINOT 2017 April 25
- 2. DDD IS AN APPROACH TO SOFTWARE DESIGN FOR COMPLEX NEEDS
- 3. Outline • Software Design activity • Software Projects issues • DDD approach • Explore the problem space with Collaborative Design • Implement the solution space with Strategic Design & Tactical Design
- 5. DESIGN IS MAKING DECISIONS
- 7. MAKING DECISIONS TO BUILD USEFUL PRODUCTS
- 8. AGILE IS HOW YOU ORGANIZE TO GET THE WORK DONE
- 9. AGILE IS HOW YOU ORGANIZE TO GET THE WORK DONE GETTING WORK DONE IS TO DESIGN
- 10. LOTS OF FAILURES HAPPENING ON SOFTWARE PROJECTS
- 11. SCRUM PRODUCT BACKLOG AS PROCESS EXCELLENCE
- 12. PRESSURE TO DELIVER SOFTWARE RELEASES ON A RELENTLESS SCHEDULE
- 13. A LACK OF DESIGN
- 14. Language Framework Library Infra JUMP INTO SPACE SOLUTION TOO QUICKLY
- 17. ANALYSIS MODEL CODE MODEL POOR SYNCHRONIZATION BETWEEN MODELS
- 18. Initial product incarnation fast to produce without care and consideration It works but no one knows how A lack of organization
- 19. DATA MODELS INSTEAD OF DOMAIN MODELS
- 21. CLIENT CONTACT Code created without a common language Different terms VS
- 22. ROOM - name ROOM - building - floor - capacity - lighting - air conditioner Code created without a common language The same term but with different meaning VS
- 23. OUR ORGANISATIONAL AND TECHNICAL DESIGNS DO NOT ALIGN WITH THE PROBLEM DOMAIN
- 25. BIG BALL OF MUD
- 30. THE MOST SIGNIFICANT COMPLEXITY IN SOFTWARE DESIGN IS NOT TECHNICAL
- 31. “Critical Complexity of most software projects is in understanding the domain itself “ Eric Evans
- 32. THE DOMAIN THE PROBLEM AREA The reality PROBLEM SPACE
- 33. THE DOMAIN IS A SPHERE OF KNOWLEDGE
- 35. DOMAINS ARE BASED ON A MODEL
- 36. THE DOMAIN MODEL Domain Knowledge Rich in Domain Model SOLUTION SPACE
- 37. 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
- 39. DDD IS ABOUT CREATING SHARED UNDERSTANDING OF THE PROBLEM SPACE
- 40. MAKE THE IMPLICIT EXPLICIT
- 41. BOUND BY LANGUAGE EXPRESSED AS DIAGRAMS EXPRESSED IN CONVERSATION EXPRESSED AS DOCUMENTATION EXPRESSED AS CODE A UBIQUITOUS LANGUAGE IS AT THE HEART OF GOOD DESIGN
- 43. BUSINESS GLOSSARY OF THE UBIQUITOUS TERMS
- 44. BUSINESS GLOSSARY AS A SHARED DOCUMENT USED AND MAINTAINED BY THE WHOLE PRODUCT TEAM
- 45. ANALYSIS MODEL CODE MODEL GOOD SYNCHRONIZATION BETWEEN MODELS Ubiquitous Language
- 48. THE PROBLEM SPACE EXPLORE THE PROBLEM SPACE
- 51. STAY IN SYNERGY WITH THE VALUES OF THE SOFTWARE AND THE BUSINESS
- 53. TAKE ALL TEAMS ON BOARD
- 55. BUSINESS USERS ARE BUSY PEOPLE
- 57. COLLABORATION AND CONSTRUCTION OF UBIQUITOUS LANGUAGE THAT MAKES DDD SO POWERFUL
- 58. Event Storming
- 59. Domain Event Command Actor Question ? Event Storming Mechanisms
- 60. CLARIFYING QUESTIONS ‣ What do you mean by … ? ‣ What might lead someone to do / need .. ? ‣ What else might happen ...?
- 61. BREAK THE PROBLEM & THE COMPLEXITY DOWN
- 62. NOT ALL THE PARTS OF THE PROBLEM ARE EQUAL
- 64. “There are no rules for determining service boundaries“ Udi Dahan
- 67. BEEF CUTS
- 71. BREAK DOWN INTO SMALLER DDD SUBDOMAINS
- 72. A car system subdomains
- 73. Subdomains of a book e-commerce platform LibraryMembership Payments Customer Support Shipping Marketing
- 74. YOU CAN'T EQUALLY SPREAD EFFORT AND QUALITY THROUGHOUT THE ENTIRE SYSTEM
- 75. ‣ WHAT ARE THE PARTS OF THE PRODUCT THAT WILL MAKE IT A SUCCESS ? ‣ WHY ARE THESE PARTS OF THE SYSTEM IMPORTANT ? ‣ WHY CAN’T THEY BE BOUGHT OFF THE SHELF ?
- 76. YOU NEED TO UNDERSTAND THE BUSINESS STRATEGY
- 80. Paper justifying why the product is a good idea Whiteboard with salient points Shared understanding of what is core CAPTURE THE CORE DOMAINS VISION
- 81. A car system subdomains
- 82. Partitioned subdomains of a book e-commerce platform BookMembership Payments Customer Support Shipping Marketing (Core Domain) (Generic Domain) (Supporting Domain) (Generic Domain) (Supporting Domain) (Core Domain)
- 83. TREAT YOUR CORE DOMAIN AS A PRODUCT
- 84. THE CORE DOMAIN REQUIRES YOUR BEST DEVELOPERS
- 85. DESGIN THE PRODUCT IN THE SOLUTION SPACE
- 86. Ideally, one-to-one mapping between domain models and subdomains BookMembership Payments Customer Support Shipping Marketing (Core Domain) (Generic Domain) (Supporting Domain) (Generic Domain) (Supporting Domain) (Core Domain) Regular shipping Priority shipping
- 87. MODEL-DRIVEN DESIGN IS HARD
- 88. MULTIPLE MODELS CRUD Domain Model Transaction script Anemic CQRS Rich object-oriented model
- 90. KEEP THE CODE MODEL CLEAN OF TECHNICAL CONCERNS AND FOCUS ON THE DOMAIN
- 91. THE PRODUCT VIEW WITH DDD The Domain Model The application layer is the client of the domain layer and represent the use case of the product The logic layer (application Service) represents the logic processes and concepts of the domain infrastructure UI
- 92. CUSTOMER << Authentication Context >> User/Mdp << Orders Context >> Method of payment << Reviewer Context>> Nb of stars BUSINESS USE CASE BUSINESS USE CASE BUSINESS USE CASE LARGE AMBIGIOUS MODEL
- 94. USER AUTHENTICATION BOUNDED CONTEXT CUSTOMER ORDERS BOUNDED CONTEXT REVIEWER EVALUATION BOUNDED CONTEXT DIVIDE LARGE AND COMPLEX MODEL INTO BOUNDED CONTEXTS
- 95. SERVICE PRIORITY BOUNDED CONTEXT SERVICE PAYMENT BOUNDED CONTEXT SERVICE REGULAR BOUNDED CONTEXT SERVICE PROMOTION BOUNDED CONTEXT ALIGNMENT WITH THE BUSINESS VISION FOR THE E-BOOK PLATFORM
- 98. USER INTERFACE BOUNDED CONTEXT A BOUNDED CONTEXT B BOUNDED CONTEXT USERINTERFACE OUR SYSTEM AS A COLLECTION OF BOUNDED CONTEXTS
- 99. A TEAM OF PROFESSIONALS WHICH OWNS THE CONTEXT WILL MAKE GOOD CHOICES
- 100. BOUNDED CONTEXT IS OWNED ENTIRELY BY ONE PRODUCT TEAM
- 101. UI + SERVICE DB PRIORITY BOUNDED CONTEXT UI + SERVICE DB PAYMENT BOUNDED CONTEXT UI + SERVICE DB REGULAR BOUNDED CONTEXT UI + SERVICE DB PROMOTION BOUNDED CONTEXT Aligning with the business vision & BC segregation
- 102. AUTONOMY CONTEXT
- 104. SIMPLE RULES FOR COMMUNICATION BETWEEN BOUNDED CONTEXTS
- 105. DDD MAXIMISES OUR ABILITY TO DELIVERY VALUE TO COSTUMERS
- 106. DDD MAXIMISES OUR ABILITY TO DELIVERY VALUE TO CUSTOMERS AND REDUCES COST
- 107. ARCHITECTURE TOOLS THAT SUPPORT DDD
- 108. Cusomer Support Shipment Payment Marketing Book Membership Marketing Book Payment Shipping Membership Customer Support Reporting Custom functional delivery team Flow of information Cross cutting Context Map
- 109. Third Party Context Shipping Context Pricing Context Legacy Context Listing Book Context Loyalty Subdomain Open Host Service Downstream Partenership Upstream Upstream DownstreamUpstream Anti Corruption Layer Context Map with integration strategies
- 110. MICROSERVICES
- 112. CONCLUSION
- 113. ‣ Design is the art of trade-off ‣ DDD enhances synergy and alignment between teams ‣ DDD focus on main concepts : ‣ Ubiquitous Language, ‣ Bounded Context, ‣ Core Domains CONCLUSION
- 114. QUESTIONS