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.
2. Multiple Models with
Multiple Perspectives in
a Cross-Functional Team
Case Study From Healthcare
KanDDDinsky 2023
Mufrid Krilic,
Domain-Driven Design Coach,
CoWork, Norway
3. About myself….
• Developer, architect, agile and
technical coach
• Healthcare, Telecom, Insurance
• “Domain-Driven Design enthusiast”
• Feel free to reach out!
• www.linkedin.com/in/mufrid/
• mufrid@cowork.no
Crafting Your Digital Confidence
4. CoWork - something
to inspire you
• Trust-Based Leadership in Practice
Tight-Loose-Tight - TLT
Crafting Your Digital Confidence
6. Why this 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
7. The topics to be covered
• Strategies to learn complex domains
• Domain problem decomposition
• Aligning different perspectives in a cross-functional team
• Delivering value in legacy constrained environments
• Modeling breakthrough
10. Questions at menti.com 8937 4165
▪ For patients with identical diagnoses sometimes the
treatment has the best effect when done in a group of
patients
▪ Examples from different subdomains in healthcare:
• Conversation therapy groups in psychiatry
• Training sessions post-injury
Domain: Healthcare - Group Treatment
12. Questions at menti.com 8937 4165
The business goal
constraint
• “Replace the legacy system”
• It must work “everywhere” and for
“everyone”
• Is this really a business goal?
• However, reality in many
organizations
13. Questions at menti.com 8937 4165
Legacy system
constraint
• ….or the opportunity?
• Works “everywhere” and for
“everyone”
• Why are we replacing it?
• “Complex systems run as broken
systems.”
• Quote from “How Complex Systems
Fail” by Richard I. Cook
14. Questions at menti.com 8937 4165
The team and the
knowledge
constraint
• No prior/limited knowledge of
the domain
• Developers
• Tester
• Product Owner
• Very knowledgeable in the domain
• Very good overview of customer’s organization
and history
• Apprehensive that the customers might be using
the legacy system in “unpredictable” ways
• 4 developers
• 1 QA
• 1 Product owner
16. We deal with complexity by
incentivize learning!
17. Questions at menti.com 8937 4165
Two Mindsets
• What kind of problems are you working on?
• Simple
• Complicated
• or Complex Problems
18. Simple problems -> no need for TLT!
Simple Problems
Best Practice
Rational Decision Making
Standards
5. Our Mission
4. Our Users
3. Our Plans
2. My Role
1. My Expertise
Automate!
Outer Alignment
Inner Alignment
19. If you have previous experience, stick to the plan!
Complicated Problems
We have previous
experience
We can trust the plan
We can trust our judgement to
guide the decisions
5. Our Mission
4. Our Users
3. Our Plans
2. My Role
1. My Expertise
Outer Alignment
Inner Alignment
20. Hypothesis-driven development for
complex problems
Complex Problems
Never done before
Learn from Failure
Challenge your
assumptions
We lack experience
5. Our Mission
4. Our Users
3. Our Plans
2. My Role
1. My Expertise
Outer Alignment
Inner Alignment
21. Questions at menti.com 8937 4165
Combining leadership approach with
strategic design
• Tight-Loose-Tight
• Discover purpose and needs (T)
• Evaluating multiple models (L)
• Challenge your assumptions (T)
22. Questions at menti.com 8937 4165
TLT argues for
Collaborative
Modeling
• Collaborative Modeling workshops
• Discovering purpose and needs
• All the right people in the same
room
• Different perspectives!
• End-users and stakeholders from
different departments
• To challenge our assumptions
24. How to learn a new domain?
1.Discover Use Cases
2.Drill into scenarios using collaborative modeling techniques
• Ask a bunch of questions
3.Listen!
4.Repeat step 2 on different or same(!) scenarios
• Ask (hopefully) the right questions ☺
25. Questions at menti.com 8937 4165
Use-Case
Approach
• Pre-workshop conversations
• Identify the most common use
cases
• or the ones with most “pain”
26. Questions at menti.com 8937 4165
▪ Setting up a group
• Planning
▪ Conducting group appointments
• Check-in process
Group Treatment Use Cases
55. Questions at menti.com 8937 4165
Data Ownership
• A business term is defined as a set
of data properties
56. Questions at menti.com 8937 4165
Functional
Decomposition
• Boundaries in the system follow the
function that a user needs to do
hers/his job
• Classic approach
• Subdomain = Function
59. Data Ownership in Domain Model –
Functional Decomposition
• One single “Group” for different functions
• 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
60. Questions at menti.com 8937 4165
Role-based
decomposition
• Boundaries in the system based on
which roles perform different
functions
• Leads to more task-oriented model
• Subdomain = Role based function
61.
62.
63. 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
64. Questions at menti.com 8937 4165
Time- and role-based
decomposition
• Boundaries in the system based on
which roles perform different
function at different times
• Supports context-oriented systems
• Subdomain = Role-based function in
a user context
65.
66.
67. 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
68. Questions at menti.com 8937 4165
About Functional
Decomposition
• Customer/end-user needs are
hidden behind functions!
• No incentives to decompose
• Pull towards canonical domain
model
70. Questions at menti.com 8937 4165
End-users need
flexibility
• Somatic Rehabilitation
• Different courses
• Different diagnosis
• Psychiatric Therapy
• Adult groups
• Pediatric groups
• Different Locations
71. Questions at menti.com 8937 4165
Flexibility and
complexity
• Allowing flexibility everywhere calls
for highly customizable systems
• Works for “everyone” and
“everywhere”
• High level of customization => high
complexity
• Configuration permutations
72. Questions at menti.com 8937 4165
Flexibility within a
Bounded Context
• Different bounded contexts for
different end-user needs
• The degree of customization in a
system is constrained to bounded
contexts
74. Questions at menti.com 8937 4165
Role-based
decomposition
• Boundaries in the system based on
which roles perform different
functions
• Leads to more task-oriented model
• Subdomain = Role based function
75.
76. Questions at menti.com 8937 4165
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
77. Decomposition approach with
respect to the problem we are facing
Complex Problems
Never done before
Learn from Failure
Challenge your
assumptions
We lack experience
5. Our Mission
4. Our Users
3. Our Plans
2. My Role
1. My Expertise
Outer Alignment
Inner Alignment
78. Team Maturity by Levels of Alignment
Organization Steering
Write unit
tests
Become
better
developer
Deliver new
feature
Clinically effective
group treatment for
diverse patient needs
Different user
needs in group
treatment in
somatic and
psychiatry
Outer Alignment
Inner Alignment
5. Mission
4. User
3. Project
2. Role and process
1. Expertise
Developers,
Product
Owner,
Tester
Product Owner, Tester
Using appropriate
decomposition
approach to reach
higher
Level of Alignment
80. Questions at menti.com 8937 4165
Boundaries by Abstractions
Use appropriate abstraction:
• Repository
• Namespaces
• Whatever might be available
in your programming
environment
81. Questions at menti.com 8937 4165
Bounded Models
• Patient attendance
incl. no-show
• Cancelled appointments
• Patients exempted from
payment
• Specialists
• Patients
• Appointments
• Location
• Reference to § in law for psychiatry
84. Questions at menti.com 8937 4165
Context Mapping
• Group Check-in has relation to three other contexts
• Patient Visit
• Patient Billing
• Scheduling
85. Questions at menti.com 8937 4165
Which relation describes our
situation best?
• “upstream-downstream relationship […]”
• "the upstream team may succeed independently of the fate of the
downstream team, [...]
• Establish a clear customer/supplier relationship between the two teams
• Negotiate and budget tasks for downstream requirements
• (Source: DDD Reference by Eric Evans)
86.
87. Questions at menti.com 8937 4165
Using dependencies to our
advantage
• It turned out that dependencies were working in our favor
• Other teams could help us achieve the goal with relatively
little work on their side
88. Questions at menti.com 8937 4165
Solved by
navigating to
other contexts
using IDs
patientID
appointmentID
UI
Composition
89. Questions at menti.com 8937 4165
UI Composition
• Works well as context integration
pattern in a multi-team distributed
environment
• Possible in most scenarios
• Legacy systems “compliant”
90. Questions at menti.com 8937 4165
Context Maps revealing possibility
for early release
• Achieving full autonomy could mean we need to do all the
work ourselves
• Group Planning
• Negotiating deliveries with other teams to release early
• Group Check-In
92. Questions at menti.com 8937 4165
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!
93. Questions at menti.com 8937 4165
Distilling the
Domain with
Pure Domain Stories
• Capturing the very essence of the
business processes
Questions to ask:
• How would you do your work
without the software system?
• What are you trying to achieve?
• Why are you doing this?
96. 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
97. Questions at menti.com 8937 4165
Decompositions
by business
capabilities
• Boundaries in the system follow the
capabilities that the business offers
its’ customers
• Subdomain = Business Capability
• Subdomain ≠ Function
• Foundation for the product
architecture
98.
99.
100. 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
101. Questions at menti.com 8937 4165
So…. Did we do
anything about it?
• Nothing ☺
• This insight came at slightly
inconvenient time
• How committed are you to the
model you have chosen?
• What is your TLT “mandate”?
102. Questions at menti.com 8937 4165
Product architecture
• There are some product related decisions to be made.
• Which users are we tailoring our products for?
• What is the cost of customizing the product for diverse user
groups?
• What is the cost of developing separate products for separate user
groups?
104. Questions at menti.com 8937 4165
So…. what have we learned?
• Collaborative Learning by asking the right questions and
listening
• Legacy Systems constrains your thinking
• Levels of Alignment helps you respect different
perspectives
• There is always another model
• ….but modeling insights might come at most
“inconvenient” times
• Data Ownership as a tool to validate the model
• Context Mapping as a tool to discover value chains