Data Ownership in
Legacy Systems
Building a Foundation for
Data Mesh
Software Craftspeople India Community, Online 2023-11-22
Mufrid Krilic, Domain-Driven Design Coach
CoWork, Norway
Slide 2
Slide 2 text
About myself….
• Developer, architect, agile and
technical coach
• Healthcare, Telecom, Insurance
• “Domain-Driven Design enthusiast”
Crafting Your Digital Confidence
Slide 3
Slide 3 text
CoWork - something
to inspire you
• Trust-Based Leadership in Practice
Tight-Loose-Tight - TLT
Crafting Your Digital Confidence
Slide 4
Slide 4 text
Some light reading
Slide 5
Slide 5 text
Takeaways after the session
• Different perspectives between application development and
data analysis
• Understanding needs for business insights with Domain
Storytelling
• Establishing data ownership with Domain-Driven Design
Slide 6
Slide 6 text
On Different Perspectives
Application Development and Data Analysis
Slide 7
Slide 7 text
The problem we are solving
• Being data-driven is a mandatory in modern business
• However ….
• Data management at scale is highly complex area with socio-
technical implications
Slide 8
Slide 8 text
Different
perspectives
• Application Development
• Data Analysis
• Operational data
• Transaction based and state-aware
• Analytical data
• Aggregated business events to
provide future insight or retrospect
Slide 9
Slide 9 text
Organizational
Legacy
• Common to find a team for data
analysis and reporting
• Separate from application
development
• Based on a real needs for different
data model for analytical data
• Data model for operational data is
usually not adequate
Slide 10
Slide 10 text
No content
Slide 11
Slide 11 text
Four Principles
1. Domain-oriented data ownership
2. Data as a product
3. Self-served data platform
4. Federated Computational
Governance
Slide 12
Slide 12 text
Established
Domain
Boundaries
• Prerequisite for Data Mesh!
• «domain-oriented decentralized data
ownership and architecture»
Slide 13
Slide 13 text
Domain-oriented?
• Data ownership closely aligned with
the data source
• Multiple autonomous yet integrated
models
Slide 14
Slide 14 text
How to Reduce
the Gap?
• Reducing the gap between the
operational and analytical data
addresses complexity with socio-
technical approach
• Combined with decentralization to
address scaling
• Can we take a different approach?
• Modelling of application data
Slide 15
Slide 15 text
Domain-Driven Design
Principles of Strategic DDD
Slide 16
Slide 16 text
No content
Slide 17
Slide 17 text
Strategic DDD
• Focusing on Core domain
• Problem and solution space
• Subdomains and Bounded Contexts
• Linguistic boundaries
• Ubiquitous Language
• The two pillars of DDD
Slide 18
Slide 18 text
Core Domain
• The thing that distinguishes you
from the competitors
• “Not every part of the system will be
well-designed”
• Generic subdomain
• Supporting subdomain
Slide 19
Slide 19 text
Problem Space
and
Solution Space
Problem space
• Domain analysis to discover inherent
Subdomains
Solution space
• Domain modeling to discover
corresponding Bounded Contexts
• Hard to find 1:1 mapping though
Slide 20
Slide 20 text
Linguistic
Boundaries
Ubiquitous Language
• The same language everywhere
• Conversations
• Documentation
• Code
Slide 21
Slide 21 text
The Two Pillars of
DDD
1. Ubiquitous Language
2. Bounded Context
Bounded contexts in your application
are defined by linguistic boundaries
Slide 22
Slide 22 text
Cross-Functional
Collaboration
• Build software in a way that domain
experts would have built it
themselves
• Discovery process where everyone,
including domain experts, learn and
understand more about the domain
Slide 23
Slide 23 text
Strategic DDD
• Focusing on Core domain
• Problem and solution space
• Subdomains and Bounded Contexts
• Linguistic boundaries
• Ubiquitous Language
• The two pillars of DDD
Slide 24
Slide 24 text
It’s Story Time
Domain of Healthcare – Group Treatment
Slide 25
Slide 25 text
▪ For patients with identical diagnoses sometimes the
treatment has the best effect when done in a group of
patients
▪ Examples from different subdomain in healthcare:
• Conversation therapy groups in psychiatry
• Training sessions post-injury
Domain: Group Treatment
Slide 26
Slide 26 text
▪ Setting up a group
• Planning
▪ Conducting group appointments
• Check-in process
Group Treatment Use Cases
Slide 27
Slide 27 text
No content
Slide 28
Slide 28 text
Group Treatment Planning
Somatic Department
Rehabilitation after lifestyle affected diagnosis
Slide 29
Slide 29 text
No content
Slide 30
Slide 30 text
No content
Slide 31
Slide 31 text
No content
Slide 32
Slide 32 text
No content
Slide 33
Slide 33 text
No content
Slide 34
Slide 34 text
No content
Slide 35
Slide 35 text
Group Treatment Check-In
Somatic Department
Rehabilitation after lifestyle affected diagnosis
Slide 36
Slide 36 text
No content
Slide 37
Slide 37 text
No content
Slide 38
Slide 38 text
No content
Slide 39
Slide 39 text
No content
Slide 40
Slide 40 text
No content
Slide 41
Slide 41 text
Group Treatment Planning
Psychiatric Department
Adult Psychiatry
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
No content
Slide 46
Slide 46 text
No content
Slide 47
Slide 47 text
Group Treatment Check-In
Psychiatric Department
Adult Psychiatry
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
No content
Slide 52
Slide 52 text
No content
Slide 53
Slide 53 text
No content
Slide 54
Slide 54 text
Data Ownership and
Modeling
On different approaches to application development
Slide 55
Slide 55 text
Data Ownership
• A business term is defined as a set
of data properties
Slide 56
Slide 56 text
Functional
Decomposition
• Boundaries in the system follow the
function that a user needs to do
hers/his job
• Classic approach
• Subdomain = Function
Slide 57
Slide 57 text
Group Treatment in Healthcare
Slide 58
Slide 58 text
Domain Model
Slide 59
Slide 59 text
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
Slide 60
Slide 60 text
Role-based
decomposition
• Boundaries in the system based on
which roles perform different
functions
• Leads to more task-oriented model
• Subdomain = Role based function
Slide 61
Slide 61 text
No content
Slide 62
Slide 62 text
No content
Slide 63
Slide 63 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 64
Slide 64 text
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
Slide 65
Slide 65 text
No content
Slide 66
Slide 66 text
No content
Slide 67
Slide 67 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 68
Slide 68 text
Aligned with the Business?
The first principle of Data Mesh
“Domain-oriented decentralized data ownership and architecture”
Slide 69
Slide 69 text
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 70
Slide 70 text
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?
Slide 71
Slide 71 text
Group Planning
Somatic Department
Slide 72
Slide 72 text
Group Planning
Psychiatric Department
Slide 73
Slide 73 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 74
Slide 74 text
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
Slide 75
Slide 75 text
No content
Slide 76
Slide 76 text
No content
Slide 77
Slide 77 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” – medical clinical services
• Physician
• Diagnosis
• Patients
• Appointments
Slide 78
Slide 78 text
More business
capabilities in
healthcare
• Neurosurgery
• Birth clinic
• Cardiology
• Etc.
Slide 79
Slide 79 text
Business
capabilities in
other domains
Insurance - Centered on products or
capabilities
• House
• Car
• Life
Instead of functions
• Such as policy, coverage
Slide 80
Slide 80 text
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?
Slide 81
Slide 81 text
Conclusion and Takeaways
Slide 82
Slide 82 text
About Functional
Decomposition
• Customer/end-user needs are
hidden behind functions!
• No incentives to decompose
• Pull towards canonical domain
model
• One of the main reasons behind the
gap between operational data
model and needs for data-insight
aligned model
Slide 83
Slide 83 text
Data-Driven
• Consider modeling around Business Capabilities to unlock the
real Business Needs
• Reducing the gap between operational and analytical data
needed for business insights
Slide 84
Slide 84 text
Language as a
tool
• The same domain term in different
subdomains is defined with
different or possibly overlapping
set of data properties
• Use domain language to find
appropriate level for decomposition
Slide 85
Slide 85 text
Takeaways
▪ Respect and align different needs for application
development and data analysis
– Data Mesh
▪ Different approaches to modeling in application
development to get closer to the real business needs
– Avoid functional decomposition
▪ Establish data ownership with Domain-Driven Design
Ella Fitzegerald –
«They Cant’t Take That Away From Me»