Share
Embed
Slide 1
Slide 1 text
The most important question
in software industry
Slide 2
Slide 2 text
Who is the User?
Slide 3
Slide 3 text
No content
Slide 4
Slide 4 text
Who is the User?
Slide 5
Slide 5 text
When using a software product,
in any moment,
the users are…
Slide 6
Slide 6 text
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….
Slide 7
Slide 7 text
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….
Slide 8
Slide 8 text
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….
Slide 9
Slide 9 text
Who is the User?
• Somebody solving a business
problem through abstraction of reality
• Somebody operating under a set of
constraints
• Somebody with specific needs
Slide 10
Slide 10 text
Who is the User?
• Somebody with specific needs
Slide 11
Slide 11 text
Users vs.
Software Products
• Why do we keep on building systems
with generic models of user’s needs?
Slide 12
Slide 12 text
Who is the User?
Why is this “The Most Important Question in Software Industry”?
Because…. this is why complex IT-systems fail!
Slide 13
Slide 13 text
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
Slide 14
Slide 14 text
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)
Slide 15
Slide 15 text
Practical
Domain-Driven Design
Case Study From Healthcare
TDC 2025
Mufrid Krilic,
Domain-Driven Design Coach
CoWork, Norway
Slide 16
Slide 16 text
Four Step Journey
1. Strategies to learn complex domains
2. Domain problem decomposition
3. Aligning user’s perspective with code structure
4. Modeling breakthrough
Slide 17
Slide 17 text
Blog:
mufridk.medium.com
Slide 18
Slide 18 text
Let’s start with the story….
Slide 19
Slide 19 text
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
Slide 20
Slide 20 text
The Team
….and the constraints
Slide 21
Slide 21 text
Questions at menti.com 3726 8507
The business goal
constraint
• “Replace the legacy system”
• It must work “everywhere” and for
“everyone”
Slide 22
Slide 22 text
Questions at menti.com 3726 8507
Legacy system
constraint
Works “everywhere” and for “everyone”
Slide 23
Slide 23 text
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
Slide 24
Slide 24 text
Questions at menti.com 3726 8507
Knowledge
Constraint
Rather limited domain
knowledge in the team
• Developers
• Tester
Slide 25
Slide 25 text
Questions at menti.com 3726 8507
Knowledge
Opportunity!
Domain Expert turned
Product Owner
“customers might be
using the legacy system in
unpredictable ways”
Slide 26
Slide 26 text
The cross-functional constraint
1 QA
1 Product
Owner
4
developers
UX-designer?
Operations?
Slide 27
Slide 27 text
Four Step Journey
1. Strategies to learn complex domains
2. Domain problem decomposition
3. Aligning users’ perspectives with code structure
4. Modeling breakthrough
Slide 28
Slide 28 text
Strategies to
Learn Complex
Domains
Slide 29
Slide 29 text
How to learn a complex domain?
Discover
Pain-points
Drill into
scenarios
Listen!
Slide 30
Slide 30 text
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
Slide 31
Slide 31 text
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!
Slide 32
Slide 32 text
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
Slide 33
Slide 33 text
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
Slide 34
Slide 34 text
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.
Slide 35
Slide 35 text
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
Slide 36
Slide 36 text
No content
Slide 37
Slide 37 text
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
Slide 38
Slide 38 text
Group Therapy Planning
Somatic Department
Rehabilitation after lifestyle affected diagnosis
Slide 39
Slide 39 text
No content
Slide 40
Slide 40 text
No content
Slide 41
Slide 41 text
No content
Slide 42
Slide 42 text
No content
Slide 43
Slide 43 text
No content
Slide 44
Slide 44 text
No content
Slide 45
Slide 45 text
Group Therapy Planning
Psychiatric Department
Adult Psychiatry
Slide 46
Slide 46 text
No content
Slide 47
Slide 47 text
No content
Slide 48
Slide 48 text
No content
Slide 49
Slide 49 text
No content
Slide 50
Slide 50 text
No content
Slide 51
Slide 51 text
Group Therapy Check-In
Somatic Department
Rehabilitation after lifestyle affected diagnosis
Slide 52
Slide 52 text
No content
Slide 53
Slide 53 text
No content
Slide 54
Slide 54 text
No content
Slide 55
Slide 55 text
No content
Slide 56
Slide 56 text
No content
Slide 57
Slide 57 text
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
Slide 58
Slide 58 text
Domain
Problem
Decomposition
Slide 59
Slide 59 text
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
Slide 60
Slide 60 text
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
Slide 61
Slide 61 text
Group Treatment in Healthcare
Slide 62
Slide 62 text
Domain Model
Slide 63
Slide 63 text
Data Ownership –
Functional Decomposition
• “Group” is defined as a set of properties needed to perform
all the functions
Slide 64
Slide 64 text
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
Slide 65
Slide 65 text
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
Slide 66
Slide 66 text
No content
Slide 67
Slide 67 text
Who is the user?
Slide 68
Slide 68 text
No content
Slide 69
Slide 69 text
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
Slide 70
Slide 70 text
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
Slide 71
Slide 71 text
No content
Slide 72
Slide 72 text
Who is the user?
Slide 73
Slide 73 text
No content
Slide 74
Slide 74 text
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
Slide 75
Slide 75 text
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
Slide 76
Slide 76 text
Four Step Journey
1. Strategies to learn complex domains
2. Domain problem decomposition
3. Aligning users’ perspective with code structure
4. Modeling breakthrough
Slide 77
Slide 77 text
Codebase
Structure
Slide 78
Slide 78 text
Questions at menti.com 3726 8507
End-users need
flexibility
• Somatic Rehabilitation
• Different courses
• Different diagnosis
• Psychiatric Therapy
• Adult groups
• Pediatric groups
• Different Locations
Slide 79
Slide 79 text
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
Slide 80
Slide 80 text
Questions at menti.com 3726 8507
Flexibility within a
boundary
The degree of customization in
a system is constrained to the
boundaries
Slide 81
Slide 81 text
What did we do?
Slide 82
Slide 82 text
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
Slide 83
Slide 83 text
No content
Slide 84
Slide 84 text
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
Slide 85
Slide 85 text
Multiple Models
Reflected in Code Structure
Slide 86
Slide 86 text
Boundaries by Abstractions
Use appropriate abstraction:
• Repository
• Namespaces
Slide 87
Slide 87 text
Bounded Models
• Patient attendance
incl. no-show
• Cancelled appointments
• Patients exempted from payment
• Specialists
• Patients
• Appointments
• Location
• Reference to § in law for psychiatry
Slide 88
Slide 88 text
Four Step Journey
1. Strategies to learn complex domains
2. Domain problem decomposition
3. Aligning users’ perspectives with code structure
4. Modeling breakthrough
Slide 89
Slide 89 text
Finally!
Understanding
the Domain
Slide 90
Slide 90 text
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!
Slide 91
Slide 91 text
Questions at menti.com 3726 8507
Distilling the
Domain with
Pure Domain Stories
Capturing the very
essence of the business
processes
Slide 92
Slide 92 text
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?”
Slide 93
Slide 93 text
Modeling Breakthrough
There were some hints along the way
Slide 94
Slide 94 text
Group Planning
Somatic Department
Slide 95
Slide 95 text
Group Planning
Somatic Department
Slide 96
Slide 96 text
Group Planning
Psychiatric Department
Slide 97
Slide 97 text
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
Slide 98
Slide 98 text
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
Slide 99
Slide 99 text
No content
Slide 100
Slide 100 text
No content
Slide 101
Slide 101 text
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
Slide 102
Slide 102 text
The cross-functional team!
1 QA
1 Product
Owner
4
developers
Field
Specialist
M
issing!
Working in legacy systems turns
specialists into generalists!
Slide 103
Slide 103 text
Questions at menti.com 3726 8507
So…. Did we do
anything about it?
Nothing ☺
How committed are you
to the model you have
chosen?
Slide 104
Slide 104 text
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
Slide 105
Slide 105 text
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
Slide 106
Slide 106 text
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
Slide 107
Slide 107 text
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
Slide 108
Slide 108 text
Wrapping up
Slide 109
Slide 109 text
Practical
Domain-Driven
Design
• Is Domain-Driven Design something
for you?
Slide 110
Slide 110 text
Developers
• Structuring the code base
• Naming things
• Names exist within a context
Slide 111
Slide 111 text
Architects
• Finding boundaries
• Listening to Field Specialists
• Data ownership as feedback tool
Slide 112
Slide 112 text
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
Slide 113
Slide 113 text
Testers
• Capturing the user context under
which system is being used
• The real-life specific test setup
Slide 114
Slide 114 text
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
Slide 115
Slide 115 text
No content
Slide 116
Slide 116 text
Applying Domain-Driven Design
is about
providing optionality!
Choosing the right model for your context
Slide 117
Slide 117 text
There is always another model
but….
modeling insights might come at
most “inconvenient” times
Slide 118
Slide 118 text
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
Slide 119
Slide 119 text
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
Slide 120
Slide 120 text
Thank you!
Slide 121
Slide 121 text
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