Practical Domain-Driven Design - Case Study from Healthcare

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 which leads to different perceptions of subdomains and bounded contexts.

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 in resulting bounded contexts.

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

Transcript

1. Practical Domain-Driven Design Case Study From Healthcare Booster Conference 2025 Mufrid Krilic, Domain-Driven Design Coach CoWork, Norway
2. My motivation for giving the talk «At times, it is bewildering to read all of the material on #DomainDrivenDesign posted here. Close to zero talk about the actual models being fleshed out or related breakthroughs, which, let's face it, are at the heart of it.» - Yves Reynhout on LinkedIn
3. What about you? • Could this talk be of any use to you? • What is your motivation?
4. Is coding your main motivation? • Highlights in this talk: • Structuring the code base • Data ownership • Naming things
5. Is architecture your main motivation? • Highlights in this talk: • Finding boundaries • Complexity analysis
6. Is UX your main motivation? • Highlights in this talk: • Understanding relation between user perspective and inner system workings • Tools to enhance user-centered communication within the team
7. Is testing your main motivation? • Highlights in this talk: • Answering the question • Who is the user? • Capturing the user context under which system is being used • the real-life test setup
8. Is team leadership your main motivation? • Highlights in this talk: • What cross-functional team really means? • Developing technology strategies based on modeling breakthroughs
9. Let’s start with the story….
10. Four Step Journey 1. Strategies to learn complex domains 2. Domain problem decomposition 3. Aligning stakeholders’ perspectives with code structure 4. Modeling breakthrough
12. Questions at menti.com 6720 3580 ▪ 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
13. The Team ….and the constraints
14. Questions at menti.com 6720 3580 The business goal constraint • “Replace the legacy system” • It must work “everywhere” and for “everyone”
15. Questions at menti.com 6720 3580 Legacy system constraint Works “everywhere” and for “everyone”
16. Questions at menti.com 6720 3580 Legacy system opportunity! • Why are we replacing it? • “Complex systems run as broken systems.” • “How Complex Systems Fail” by Richard I. Cook
17. Questions at menti.com 6720 3580 Knowledge Constraint Rather limited domain knowledge in the team • Developers • Tester
18. Questions at menti.com 6720 3580 Knowledge Opportunity! Domain Expert turned Product Owner “customers might be using the legacy system in unpredictable ways”
19. The cross-functional constraint 1 QA 1 Product Owner 4 developers UX-designer? Operations?
20. Four Step Journey 1. Strategies to learn complex domains 2. Domain problem decomposition 3. Aligning stakeholders’ perspectives with code structure 4. Modeling breakthrough
21. Strategies to Learn Complex Domains
22. How to learn a new domain? Discover Pain-points Drill into scenarios Listen! Repeat step 2 • Same or different scenario
23. Questions at menti.com 6720 3580 Discover Pain-Points • Identify the areas which “hide” the pain-points • Domain experts might hint about “difficult” areas without being very precise about it
24. Questions at menti.com 6720 3580 Scenario = Communication Opportunity! • Everyone in the team has a stake in scenarios! • Exploit scenarios to build shared understanding in the team
25. Questions at menti.com 6720 3580 How to communicate scenarios? • Everyone in the team might prefer different methodology • User Journeys • Sequence diagrams • Test Cases • etc.
26. Questions at menti.com 6720 3580 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
28. Questions at menti.com 6720 3580 ▪ Group Therapy: Setting up a group • Planning ▪ Group Therapy: Conducting group appointments • Check-in process Domain specific areas that “hide” difficult problems
29. Group Therapy Planning Somatic Department Rehabilitation after lifestyle affected diagnosis
36. Group Therapy Planning Psychiatric Department Adult Psychiatry
42. Group Therapy Check-In Somatic Department Rehabilitation after lifestyle affected diagnosis
48. Questions at menti.com 6720 3580 Four Step Journey 1. Strategies to learn complex domains 2. Domain problem decomposition 3. Aligning stakeholders’ perspectives with code structure 4. Modeling breakthrough
49. Domain Problem Decomposition
50. Questions at menti.com 6720 3580 Data Ownership • A business concept is defined as a set of data properties • This represents a model of the business concept in the system
51. Questions at menti.com 6720 3580 Functional Decomposition • Boundaries in the system follow the function that a user needs to do hers/his job • Classic approach • Boundary = Function
52. Group Treatment in Healthcare
53. Domain Model
54. Data Ownership – Functional Decomposition • “Group” is defined as a set of properties needed to perform all the functions
55. 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
56. Questions at menti.com 6720 3580 Role-based decomposition • Boundaries in the system based on which roles perform different functions • Leads to more task-oriented model • Boundary = Role based function
58. Who is the user?
60. 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
61. Questions at menti.com 6720 3580 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
63. Who is the user?
65. 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
66. Questions at menti.com 6720 3580 About Functional Decomposition • Customer/end-user needs are hidden behind functions! • No incentives to decompose • Pull towards canonical domain model
67. Four Step Journey 1. Strategies to learn complex domains 2. Domain problem decomposition 3. Aligning stakeholders’ perspective with code structure 4. Modeling breakthrough
68. Code Base Structure
69. Questions at menti.com 6720 3580 End-users need flexibility • Somatic Rehabilitation • Different courses • Different diagnosis • Psychiatric Therapy • Adult groups • Pediatric groups • Different Locations
70. Questions at menti.com 6720 3580 Flexibility = complexity? • Allowing flexibility everywhere calls for highly customizable systems • Works for “everyone” and “everywhere” • High level of customization => high complexity
71. Questions at menti.com 6720 3580 Flexibility within a boundary The degree of customization in a system is constrained to the boundaries
72. What did we do?
73. Questions at menti.com 6720 3580 Role-based decomposition • Boundaries in the system based on which roles perform different functions • Leads to more task-oriented model • Boundary = Role based function
75. Questions at menti.com 6720 3580 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
76. Multiple Models Reflected in Code Structure
77. Boundaries by Abstractions Use appropriate abstraction: • Repository • Namespaces
78. Bounded Models • Patient attendance incl. no-show • Cancelled appointments • Patients exempted from payment • Specialists • Patients • Appointments • Location • Reference to § in law for psychiatry
79. Four Step Journey 1. Strategies to learn complex domains 2. Domain problem decomposition 3. Aligning different perspectives with Bounded Contexts 4. Modeling breakthrough
80. Finally! Understanding the Domain
81. Questions at menti.com 6720 3580 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!
82. Questions at menti.com 6720 3580 Distilling the Domain with Pure Domain Stories Capturing the very essence of the business processes
83. Questions at menti.com 6720 3580 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?”
84. Group Planning Somatic Department
85. Group Planning Psychiatric Department
86. 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
87. Questions at menti.com 6720 3580 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
90. 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” – medical clinical services • Physician • Diagnosis • Patients • Appointments
91. The cross-functional team! 1 QA 1 Product Owner 4 developers Field Specialist M issing! Working in legacy systems turns specialists into generalists!
92. Questions at menti.com 6720 3580 So…. Did we do anything about it? Nothing ☺ How committed are you to the model you have chosen?
93. 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
94. Questions at menti.com 6720 3580 This is where the strategy comes into play • New insights and breakthroughs are input for developing technical and product strategies
95. 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
96. Wrapping up
97. Applying Domain-Driven Design is about providing optionality! Choosing the right model for your context
98. There is always another model but…. modeling insights might come at most “inconvenient” times
99. Questions at menti.com 6720 3580 So…. what have we learned? • Asking the right questions • Listening to the field specialists • Legacy Systems may significantly affect end-user’s language and mental model • Data Ownership for model validation
100. 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
101. Thank you!
102. Questions at menti.com 6720 3580 Photos • https://unsplash.com/@ratushny • https://unsplash.com/@jeshoots • https://unsplash.com/@mango_quan • www.vecteezy.com