Practical Domain-Driven Design - TDC 2025

In many cross-functional teams we encounter communication challenges between different roles in the team. Making domain experts, designers, testers, developers and tech leads align on the shared understanding is not an easy task. This is mainly due to different perspectives that each team member brings to the table, each perspective being a valid one however not adequate on its own. The different perspectives are particularly visible when reasoning about different approaches to the decomposition of the domain problem at hand.

In this case study we will go through different models of domain problem decomposition that helped align the perspectives in a cross-functional team in the healthcare domain. We will go through functional, role-based, user-context based and business capability based decomposition along with pros and cons of each approach, backed up by the feedback provided by the impact each approach had on the data ownership.

We will wrap-up with the reasoning behind the choice the team actually made and how it played out in structuring the code base and delivering value to their customers.

Transcript

1. The most important question in software industry
2. Who is the User?
4. Who is the User?
5. When using a software product, in any moment, the users are…
6. 1. Applying their own mental model of reality Solving business problems through software requires abstraction of reality Are you able to replicate that mental model while building the software product? The users are….
7. 2. Exposed to constraints External constraints might cause user to interact with the system in unexpected ways Can you replicate the same constraints while building software product? The users are….
8. 3. Operating within a context Context: The users have specific needs they are trying to fulfill in a particular moment Context changes over time The users are….
9. Who is the User? • Somebody solving a business problem through abstraction of reality • Somebody operating under a set of constraints • Somebody with specific needs
10. Who is the User? • Somebody with specific needs
11. Users vs. Software Products • Why do we keep on building systems with generic models of user’s needs?
12. Who is the User? Why is this “The Most Important Question in Software Industry”? Because…. this is why complex IT-systems fail!
13. The gap between specific needs and generic models • The users are expected to adapt to the system, not the other way around • The responsibility for fulfilling user needs is shifted to outside the system
14. The most important question in software industry “The hardest single part of building a software system is deciding precisely what to build.” (Fred Brooks, No Silver Bullet)
15. Practical Domain-Driven Design Case Study From Healthcare TDC 2025 Mufrid Krilic, Domain-Driven Design Coach CoWork, Norway
16. Four Step Journey 1. Strategies to learn complex domains 2. Domain problem decomposition 3. Aligning user’s perspective with code structure 4. Modeling breakthrough
17. Blog: mufridk.medium.com
18. Let’s start with the story….
19. Questions at menti.com 3726 8507 ▪ For patients with identical diagnoses sometimes the treatment has the best effect when done in a group of patients ▪ Examples: • Conversation therapy groups in psychiatry • Training sessions post-injury Domain: Healthcare - Group Therapy
20. The Team ….and the constraints
21. Questions at menti.com 3726 8507 The business goal constraint • “Replace the legacy system” • It must work “everywhere” and for “everyone”
22. Questions at menti.com 3726 8507 Legacy system constraint Works “everywhere” and for “everyone”
23. Questions at menti.com 3726 8507 Legacy system opportunity! • Why are we replacing it? • “Complex systems run as broken systems.” • “How Complex Systems Fail” by Richard I. Cook
24. Questions at menti.com 3726 8507 Knowledge Constraint Rather limited domain knowledge in the team • Developers • Tester
25. Questions at menti.com 3726 8507 Knowledge Opportunity! Domain Expert turned Product Owner “customers might be using the legacy system in unpredictable ways”
26. The cross-functional constraint 1 QA 1 Product Owner 4 developers UX-designer? Operations?
27. Four Step Journey 1. Strategies to learn complex domains 2. Domain problem decomposition 3. Aligning users’ perspectives with code structure 4. Modeling breakthrough
28. Strategies to Learn Complex Domains
29. How to learn a complex domain? Discover Pain-points Drill into scenarios Listen!
30. Questions at menti.com 3726 8507 Learning by Listening to Scenarios • Scenarios are well suited to detect complexity • Much better than what we call “business rules” • Avoid setting up business rules too soon
31. Questions at menti.com 3726 8507 Learning by Listening to Scenarios • Listen in each scenario! • Who is the user? • What are they trying to achieve? • Why? • Detecting user needs!
32. Questions at menti.com 3726 8507 Discover Pain-Points • Identify the areas which “hide” the pain-points • Domain experts might hint about “difficult” areas without being very precise about it
33. Questions at menti.com 3726 8507 Scenario = Communication Opportunity! • Everyone in the team has a stake in scenarios! • Exploit scenarios to build shared understanding in the team
34. Questions at menti.com 3726 8507 How to communicate scenarios? • Everyone in the team might prefer different methodology • User Journeys • Sequence diagrams • Test Cases • etc.
35. Questions at menti.com 3726 8507 How to communicate scenarios? • Something visual and simple • Meaning something that does not require any “trade-specific” knowledge • Syntax can be learnt on-the-fly • As close to the natural language as possible
37. Questions at menti.com 3726 8507 ▪ Group Therapy: Setting up a group • Planning ▪ Group Therapy: Conducting group appointments • Check-in process Domain specific areas that “hide” difficult problems
38. Group Therapy Planning Somatic Department Rehabilitation after lifestyle affected diagnosis
45. Group Therapy Planning Psychiatric Department Adult Psychiatry
51. Group Therapy Check-In Somatic Department Rehabilitation after lifestyle affected diagnosis
57. Questions at menti.com 3726 8507 Four Step Journey 1. Strategies to learn complex domains 2. Domain problem decomposition 3. Aligning users’ perspectives with code structure 4. Modeling breakthrough
58. Domain Problem Decomposition
59. Questions at menti.com 3726 8507 Data Ownership • A business concept is defined as a set of data properties • This represents a model of the business concept in the system
60. Questions at menti.com 3726 8507 Functional Decomposition • Boundaries in the system follow the function/task/action that a user performs to do hers/his job • Classic approach • Boundary = Function
61. Group Treatment in Healthcare
62. Domain Model
63. Data Ownership – Functional Decomposition • “Group” is defined as a set of properties needed to perform all the functions
64. Data Ownership – Functional Decomposition • Definition of “Group” • Physician and specialists • Patients • Appointments • Location/Venue • Patient attendance, including no-show • Patients exempted from payment • Invoice – preferred method • Diagnosis-based patient fee • Reference to § in law for compulsory interventions in psychiatry
65. Questions at menti.com 3726 8507 Role-based decomposition • Boundaries in the system based on which roles perform different functions • Leads to more task-oriented model • Boundary = Role based function
67. Who is the user?
69. Data Ownership in Domain Model – role-based decomposition “Group” planning context • Specialists • Patients • Appointments • Location • Reference to § in law for psychiatry “Group” check-in context • Patient attendance incl. no-show • Cancelled appointments • Patients exempted from payment • Invoice – preferred method • Diagnosis-based patient fee
70. Questions at menti.com 3726 8507 Time- and role-based decomposition • Boundaries in the system based on which roles perform different function at different times • Supports context-oriented systems • Boundary = Role-based function in a user context
72. Who is the user?
74. Data Ownership in Domain Model – time- and role-based decomposition “Group” planning context • Specialists • Patients • Appointments • Location • Reference to § in law for psychiatry “Group” check-in context • Patients exempted from payment • Invoice preferred method • Diagnosis-based patient fee “Group” billing context • Patient attendance, incl. no-show • Cancelled appointments
75. Questions at menti.com 3726 8507 About Functional Decomposition • Customer/end-user needs are hidden behind functions! • No incentives to decompose • Pull towards canonical domain model
76. Four Step Journey 1. Strategies to learn complex domains 2. Domain problem decomposition 3. Aligning users’ perspective with code structure 4. Modeling breakthrough
77. Codebase Structure
78. Questions at menti.com 3726 8507 End-users need flexibility • Somatic Rehabilitation • Different courses • Different diagnosis • Psychiatric Therapy • Adult groups • Pediatric groups • Different Locations
79. Questions at menti.com 3726 8507 Flexibility = complexity? • Allowing flexibility everywhere calls for highly customizable systems • Works for “everyone” and “everywhere” • High level of customization => high complexity
80. Questions at menti.com 3726 8507 Flexibility within a boundary The degree of customization in a system is constrained to the boundaries
81. What did we do?
82. Questions at menti.com 3726 8507 Role-based decomposition • Boundaries in the system based on which roles perform different functions • Leads to more task-oriented model • Boundary = Role based function
84. Questions at menti.com 3726 8507 Why? The time perspective separates the models Group Checkin is about confirming what happened in an appointment Group Planning is about how appointments are going to happen
85. Multiple Models Reflected in Code Structure
86. Boundaries by Abstractions Use appropriate abstraction: • Repository • Namespaces
87. Bounded Models • Patient attendance incl. no-show • Cancelled appointments • Patients exempted from payment • Specialists • Patients • Appointments • Location • Reference to § in law for psychiatry
88. Four Step Journey 1. Strategies to learn complex domains 2. Domain problem decomposition 3. Aligning users’ perspectives with code structure 4. Modeling breakthrough
89. Finally! Understanding the Domain
90. Questions at menti.com 3726 8507 The Business and the Legacy System • The more complex the legacy system…. • ….and the longer the system is in production • ….the more likely that the domain language will be affected …. by the language of the legacy system!
91. Questions at menti.com 3726 8507 Distilling the Domain with Pure Domain Stories Capturing the very essence of the business processes
92. Questions at menti.com 3726 8507 Facilitator’s guidance • “How would you do your work without the software system?” • “What are your needs at the particular step?” • “Why are you doing that?”
93. Modeling Breakthrough There were some hints along the way
94. Group Planning Somatic Department
95. Group Planning Somatic Department
96. Group Planning Psychiatric Department
97. Departments •Accident and Emergency Department •Anaesthesia and Surgical Services •Cancer Treatment and Medical Physics •Children and Youth Clinic •Clinical Nutrition •Communication •Department of Occupational Therapy •Dermatology •Emergency Clinic •Emergency Department Short Stay Unit •Finance •Haukeland hotel •Heart Disease •Human Resources •Internal Medicine •International Collaboration •Laboratory Medicine and Pathology •Maternity Ward •Medical Biochemistry and Pharmacology MBF •Medical Genetics •Neurology •Neurosurgery •Occupational Medicine •Occupational Outpatient Clinic •Ophthalmology •Oral Surgery •Orthopedic Clinic •Physiotherapy •Psychiatry •Radiology department •Recruitment and Temporary Staffing Office •Regional Centre for Asthma, Allergy and Other Hypersensitivity illnesses in Western Norway •Research and Development •Rheumatology •Secretariat for hospital management •Surgical Clinic •The Cancer Center for Education and rehabilitation- CCER •The Norwegian Arthritis Registry - NorArthritis •The Norwegian Porphyria Centre NAPOS •Thoracic Medicine •Treatment abroad •Tuberculosis clinic •Women's Clinic
98. Questions at menti.com 3726 8507 Decompositions by business capabilities • Boundaries in the system follow the capabilities that the business offers its’ customers • Boundary = Business Capability • Boundary ≠ Function • Foundation for the product architecture
101. Data Ownership – Decomposition by Business Capabilities “Group” – psychiatry capability • Psychologist • Psychiatrist • Diagnosis • Reference to § in law • Patients • Appointments • Location for appointment outside hospital premises “Group” – somatic rehabilitation capability • Medical supervisor of the course • Training consultant • Diagnosis • Patients • Appointments
102. The cross-functional team! 1 QA 1 Product Owner 4 developers Field Specialist M issing! Working in legacy systems turns specialists into generalists!
103. Questions at menti.com 3726 8507 So…. Did we do anything about it? Nothing ☺ How committed are you to the model you have chosen?
104. Product architecture Which users are we tailoring our products for? The cost of customizing the product for diverse user groups The cost of developing separate products for separate user groups
105. Incentives What market incentives do we have when building a product? Market might incentivize us to build a single product that can reach many customers End-users might incentivize us to build specific products for their specific needs
106. Questions at menti.com 3726 8507 This is where the strategy comes into play • New insights and breakthroughs are input for developing technical and product strategies
107. Big re-write? • Recognize the opportunities where you can steer the direction of the product development towards the strategic goals • Adapt the product model to move one step closer to the strategic goal • one opportunity at a time
108. Wrapping up
109. Practical Domain-Driven Design • Is Domain-Driven Design something for you?
110. Developers • Structuring the code base • Naming things • Names exist within a context
111. Architects • Finding boundaries • Listening to Field Specialists • Data ownership as feedback tool
112. UX-designers • Understanding relation between user perspective and inner system workings • User’s language might be very diluted after long time of using the legacy system • Some (new?) tools to enhance user- centered communication within the team
113. Testers • Capturing the user context under which system is being used • The real-life specific test setup
114. Product or Technology Leads • What cross-functional team really means? • Developing strategy based on modeling breakthroughs • Specific models for specific user needs • Specific products for specific market segments
116. Applying Domain-Driven Design is about providing optionality! Choosing the right model for your context
117. There is always another model but…. modeling insights might come at most “inconvenient” times
118. Questions at menti.com 3726 8507 Mufrid’s Heuristic for building systems in complex domains If there is just one thing to remember…. • When modeling complex domains…. • Start first with what is different • Instead of starting first with what is common
119. Thank you and reach out! • About me • Coaching individuals, teams and organizations • Helping Build Domain-Driven Product Organizations • Feel free to reach out! Helping Build Domain-Driven Product Organizations
120. Thank you!
121. Questions at menti.com 3726 8507 Photos • https://unsplash.com/@ratushny • https://unsplash.com/@jeshoots • https://unsplash.com/@mango_quan • https://unsplash.com/@jontyson • www.vecteezy.com