Software developers are generally great solution-oriented people. We propose solutions to difficult problems, we try to make life easier for our customers by shielding them from overwhelming technologies by abstracting the details and creating nice and intuitive user-interfaces. However, in enterprise business domains, what happens when the business rules of the domain are overwhelmingly complex by themselves? In such circumstances, the ability to quickly propose solutions to customers’ problems could become an disadvantage. When trying to understand complex domain a quick solution proposal could lead to wrong problem being solved. Inherent focus of a developer is on technology, not on business rules, which risks hiding the complex enterprise business rules beneath e.g. framework choices. How can one be sure that the correct solution was being applied to the correct problem? Find the right problem to solve, then focus on technology that could help solve the problem. Domain Driven Design (DDD) is a mindset for focusing on domain first when developing software. Some emerging DDD techniques offer light-weight, high-reward methods for learning complex domains while visualizing the complexities in the domain. Most notably, Event Storming and Domain Storytelling have been gaining traction recently and are astonishing methods for techies and non-techies alike. Both methods create an arena where domain knowledge can be shared among all participants in a project. In this talk I will present examples on learning the domain of healthcare and how applying Event Storming and Domain Storytelling methods helped my team to expose and embrace the complexities of the domain in our software. The methods reveal ways to deal with complexities using essential DDD patterns such as Bounded Contexts where complexity is naturally divided into different contexts that align with the boundaries that exist in the domain.

1. E N A B L I N G E F F I C I E N T H E A L T H C A R E
Cynefin Framework by Dave Snowden. Sketch by Edwin Stoop

2. E N A B L I N G E F F I C I E N T H E A L T H C A R E
Strategies to Learn Complex Domains
Mufrid Krilic, Senior Software Developer/Coach DIPS AS, Norway
Experiences from Developing Enterprise Software for Healthcare

3. E N A B L I N G E F F I C I E N T H E A L T H C A R E
 Ignited curiosity about Domain Driven Design and Event Storming
 Lessons learned when dealing with complexity in healthcare
Takeaways

4. E N A B L I N G E F F I C I E N T H E A L T H C A R E
 Definition of Complexity
– “the state of having many parts and being difficult to understand or find an
answer to”
• Cambridge Dictionary
 How to recognize complexity in a domain?
– Complexity on strategic level
– Complexity on tactical level
About complex domains

5. E N A B L I N G E F F I C I E N T H E A L T H C A R E
 Many-to-many relationships between domain terms
 Matrix-like relationships
– Use case: Admission Letters sent from Hospital
Complexity on Tactical Level

6. E N A B L I N G E F F I C I E N T H E A L T H C A R E
 Letter template depending on required treatment
– Level of Care
• Outpatient or hospitalization?
– What department?
– What is the health issue?
• Related to the field of discipline within each department
– Each discipline is related to a set of coded diagnoses that patient’s health issue fall within
• Is patient entitled to health care provided by the state?
 In total 5 parameters
Complexity in Healthcare - Admission Letters

7. E N A B L I N G E F F I C I E N T H E A L T H C A R E
 Letter template depending on a stage in admittance process
– Referral Reception Letter
• When hospital initially receives referral from patient’s GP
– Referral Evaluation Result Letter
• When hospital decides to either refer patient to another hospital or decline health care
for a valid reason
– Appointment Notice Letter
• When hospital schedules patient for a visit
– Without fixed appointment time
– With tentative time
– With fixed appointment time
 In total 6 parameters
Complexity in Healthcare - Admission Letters

8. E N A B L I N G E F F I C I E N T H E A L T H C A R E
 The matrix of parameters respectively related to required treatment
and stage of admission process yields the letter template
 Precedence between parameters on the left-hand side
 Orthogonal complexity
– Letter to next of kin, GP. Printed letter or electronic message. Cross-
department letter templates.
Complexity Revealed
Referral received
Referral rejected
Referred to another hospital
Appointment w/o fixed time
Appointment w/ tentative time
Appointment w/ fixed time
Level of care
Department
Discipline
Diagnosis
Healthcare entitlement

9. E N A B L I N G E F F I C I E N T H E A L T H C A R E
 The complexity matrix should be explicitly modeled in code
– Preferably not mixed with technological concerns
• UI framework
• Persistency technology
 Why?
– Reducing accidental complexity introduced by technology choices
– Expose inherent complexity in business rules
• Rules described in previous slides are there regardless of technology
Complexity Exposed

10. E N A B L I N G E F F I C I E N T H E A L T H C A R E
 Use Case: Referral Flow in Norwegian Hospitals
– Basic flow
• GP creates referral on behalf of patient and sends it to a relevant hospital
• Pre-sorting of received referrals followed by referral reception in each department
• Referral made ready for evaluation by a supervising physician
• Referral is evaluated by a physician
– Accepted i.e. patient is entitled for public healthcare in a hospital
– Or rejected on some formal or clinical basis
• Patient is scheduled for admittance
– Significant alternative flows
• Patient is referred to another department for supplementary treatment
• Patient is referred to another hospital for more specialized or extensive treatment
– The flow involves multiple roles and takes time to complete
Complexity on Strategic Level

11. E N A B L I N G E F F I C I E N T H E A L T H C A R E
 The complexity in the overall business process should be visible early
in the project
– Without time-consuming studies and extensive documentation
 Why?
– Can we reduce complexity on the strategic level by aligning teams with
inherent subdomains in the problem space?
• to enable teams to be efficient in dealing with complexity on tactical level
– Establishing common language between developers and the business
– Investing heavily in learning early on
• A.K.A. «Knowledge Crunching»
Complexity Exposed

12. E N A B L I N G E F F I C I E N T H E A L T H C A R E
 What is DDD?
– My personal definition or why I value DDD:
• DDD is an approach for dealing with complex problems with emphasis on learning the
domain in a close collaboration with domain experts in order to focus on the most
important problems to solve.
 The term coined by Eric Evans in 2004
– The “Blue Book”
• Tackling Complexity in the Heart of Software
About Domain Driven Design (DDD)

13. E N A B L I N G E F F I C I E N T H E A L T H C A R E
 Ubiquitous Language
– Develop domain model based on domain terms
 Bounded Context
– tackle complexity by splitting application via inherent subdomain boundaries
– The boundaries are primarily linguistic per the Ubiquitous Language
• If a domain term has different meaning in different use-cases it is an indication of
separate bounded contexts
– Example: Patient
» Patient as a subject of care
» Patient as a customer paying the bill after visiting the clinic
– Bounded Contexts are defined by the semantics of the Ubiquitous Language!
The Two Pillars of DDD

14. E N A B L I N G E F F I C I E N T H E A L T H C A R E
 Knowledge Crunching technique
– The term introduced by Eric Evans in the Blue Book
 Event Storming
– Introduced to community by Alberto Brandolini in 2013
– Discovery and collaboration with domain experts put in practice
• People with questions meet people with answers
– Massive learning and sharing of different perspectives
– Making the most important problems visible
– Unlimited modelling space
 Multiple levels
– Big picture, process modelling or software design
About Event Storming

15. E N A B L I N G E F F I C I E N T H E A L T H C A R E
– Use Case: Referral flow in Norwegian hospitals
Big Picture Event Storming

16. E N A B L I N G E F F I C I E N T H E A L T H C A R E
 Domain Event
– Orange sticky note
– Verb at past tense
– Relevant for domain experts
Big Picture Event Storming
Referral
received
from
patient’s GP
Referral for
evaluation
sent to
attending
physician
Referral
accepted
Medical
consultant
Attending
physician
How is attending
physician notified
when GP sends a
reminder on non-
evaluated referral?
Will GP send another
referral (duplicate) if
GP wants to remind
hospital about non-
evaluated referral?
 User/Actor/Persona
– Yellow sticky note
 Hot Spots
– Pink sticky note
– This is where
interesting discovery
happens

17. E N A B L I N G E F F I C I E N T H E A L T H C A R E
Complexity Revealed:
Referral From GP to Hospital

18. E N A B L I N G E F F I C I E N T H E A L T H C A R E
Complexity Revealed:
Referral Evaluation in Hospital

19. E N A B L I N G E F F I C I E N T H E A L T H C A R E
Complexity Revealed:
In-Hospital and Inter-Hospital Referral

20. E N A B L I N G E F F I C I E N T H E A L T H C A R E
 Strong hints about Bounded Contexts
– Suddenly visible when taking time into account!
• One-way communication and work hand-off between roles and tasks
– Identifying different roles in the business process
• Medical consultant makes sure received referral is ready for evaluation
• Attending physician evaluates the referral
• Planning consultant schedules patience for admittance
– Same role with different tasks at different points in time
• Attending physician evaluates received referral
• Patient is admitted but the treatment requires services from another hospital
• Attending physician refers patient to another hospital by creating new referral
 Bounded Contexts emerged only in aftermath
Lessons Learned - Big Picture Event Storming

21. E N A B L I N G E F F I C I E N T H E A L T H C A R E
 Assert perceived Bounded Contexts against the Ubiquitous Language
– Referral with different meaning in different stages of the business process
• Referral as in received referral
• Referral as in evaluated referral
• Referral as in referral to another department or hospital
 Perceived Bounded Contexts should be challenged throughout the
development process
– Learning is an iterative process, after all…..
Lessons Learned – Bounded Contexts Assertions

22. E N A B L I N G E F F I C I E N T H E A L T H C A R E
 Respect, embrace and expose inherent complexity in the domain
 Reveal complexity by applying Knowledge Crunching methods
– Event Storming, Domain Storytelling
– Get an overview of the business process in a quick and efficient way
 Assess inherent subdomains and establish Bounded Contexts
– Input for modularization in the application
 For multiple teams project align teams with subdomains and
Bounded Contexts
 Apply appropriate technology on each problem within a Bounded
Context
Lessons Learned while Applying DDD

23. E N A B L I N G E F F I C I E N T H E A L T H C A R E
 Eric Evans
– «Tackling Complexity in the Heart of Software»
• «The Blue Book»
 Vaughn Vernon
– «Implementing Domain Driven Design»
• «The Red Book»
– «Domain Driven Design Distilled»
• «The Green Book»
 Alberto Brandolini
– «Introducing EventStorming – an Act of Deliberate Collective Learning»
• Book on LeanPub
Further Reading