One way or another, each system contains some kind of boundaries. I would go so far and claim that even the dreaded Big Ball of Mud systems consist of parts that could be perceived as separate though undoubtedly only under deep scrutiny. The difference is in the “thickness” of the boundaries and the measure of interrelationships between the different parts of the system, the frequency and amount of data that is passed across the fences. It is the latter that leads to increased coupling resulting in systems that are hard to maintain and hard to change. This presentation will present a story of an attempt to achieve an alignment between perceived subdomains, logical boundaries and source code structure in a legacy system. Based on the use case from healthcare we will go into technical detail on concrete steps that were followed to create a new bounded context using strategic Domain-Driven Design and 4+1 Architectural View Models.

1. Aligning Bounded Contexts with
Subdomains in Legacy Code
NDC Oslo 2021
Mufrid Krilic
Domain-Driven Design Coach
www.cowork.no

2. Training and
Coaching
• Agile Leadership
• “Tight-Loose-Tight”
• Domain-Driven Design with NDC
Workshops
• bit.ly/domainstorytelling-online
• Blog
• https://mufridk.medium.com

3. Book recommendation #1

4. Strategic Domain-Driven
Design
The Principles

5. Strategic DDD
• Focusing on Core domain
• Problem and solution space
• Subdomains and Bounded Contexts
• Linguistic boundaries
• Ubiquitous Language
• The two pillars of DDD

6. Core Domain
• The thing that distinguishes you
from the competitors
• “Not every part of the system will be
well-designed”
• Generic subdomain
• Supporting subdomain

7. Problem Space
and
Solution Space
Problem space
• Domain analysis to discover
inherent Subdomains
Solution space
• Model your application accordingly
in multiple Bounded Contexts

8. Linguistic
Boundaries
Ubiquitous Language
• The same language everywhere
• Conversations
• Documentation
• Code

9. The Two Pillars of
DDD
1. Ubiquitous Language
2. Bounded Context
Bounded contexts in your application
are defined by linguistic boundaries

10. Book recommendation #2

11. Boundaries
Why?

12. Making Sense of
the Problem
Space
• Aligning with the business
• Reducing the translation effort
• Ubiquitous Language

13. Reducing the
Cognitive Load
• Legacy Code
• Being able to navigate
• …. and understand
• Hidden boundaries in legacy code
• Look for subdomains

14. Book recommendation #3

15. Boundaries
Where?

16. Observable
boundaries
• Technical
• Network
• Containers
• Organizational
• Teams
• Departments
• Easily observable boundaries

17. Not so easily
observable?
• The “4+1” View Model of Software
Architecture
• Philippe Kruchten
• https://bit.ly/4plus1Paper

18. https://bit.ly/4plus1Paper

19. Dependencies
What are they?

20. Logical View
Dependencies
The reason for increased coupling
• The amount of data that is passed
across the boundaries

21. Cost of
Dependencies in a
Distributed System
• Distributed logical dependencies
• Across software and process views
• Across the organization
• Microservices

22. The Story Begins….
Story about a team dealing with legacy system

23. Business Case
• Physicians prescribe medications
• Integration with systems for
prescription delivery in pharmacies
• Focus on putting patient needs and
safety on the top

24. Use Case
Prescribing pre-approved medication

29. Drawn with egon.io

30. Use Case
Prescribing non-approved medication

37. Drawn with egon.io

38. Book recommendation #4

39. Looking for Subdomains
.... in Legacy Environments

40. Subdomains in
Problem Space
• Pivotal Event
• NonApprovedMedicationPrescribed
• Time-related activity
• While waiting for approval the
physician stops the prescription
process

41. Drawn with egon.io

42. Traces of Bounded
Contexts in
Development View
• Are there any established
boundaries in the Development
View?
• 4+1 Model
• .NET projects
• Namespaces

43. Dependencies in
Logical View
• Analysis of
• using statements
• .NET project references
• NuGet package references
• Http calls to remote services
• Event-based communication with
remote services

44. Bounded Contexts
…. and Context Mapping

45. DDD Context Mapping
Downstream: depending on upstream
Upstream: depended on downstream
Conformist: Upstream model referenced directly in Downstream context

46. Bounded Contexts
in Legacy Code
• Respect existing dependencies and
relationships
• Explicit decision on the amount of
work needed to break things up

47. Decision Time

48. Application
Bounded Context
• Establish observable boundary
• Visual Studio Solution
• Prescription Bounded Context
remains as is
• 1 week time-box
• Summarize lessons learned
regardless of the outcome

49. Step One
Establish Visual Studio Solution

50. Move existing .NET projects
• Between solutions within the same repository
• git mv
• Exclude/Include Project
Code compiles and unit tests run

51. Integration tests?
• Valuable enough feedback with unit
tests only?
• Integration/E2E tests
• Harder to maintain
• Can provide runtime feedback

52. Work on E2E tests?
• Pros
• Early feedback on bounded context/subdomain alignment
• Cons
• Considerable work needed just to get the tests running
• Could actually slow down the feedback loop
Focus on unit tests only at this stage

53. Step Two
Cleaning up obsolete references

54. Made obsolete in step one
• .NET project references
• using statements
Uncovers hidden dependencies

55. Classes and interfaces
- Defined in Application BC
- Referenced in Prescription BC

56. Stable Abstraction
Principle
Packages that are maximally
stable should be maximally
abstract.
• Extract common type definitions to
a separate module

57. DDD Context Mapping
Shared Kernel: Two contexts share a subset of the domain model

58. Step 3
Make E2E tests to run

59. The end of the story….
• Some E2E tests in Prescription context required DLLs from
Application context
• Why?

60. Valid business reason for Prescription BC to refer to Application BC
- Beware of Circular Dependencies!

61. Business requirement unlocked
• As a physician while prescribing a non-approved medicament
• I need to see prior applications for the same medicament
• To be able to prescribe non-approved medicaments on a life-long
basis if required by patient condition
Requires dependency from Prescription BC to Application BC

62. Can we avoid
circular
dependencies?
• 4+1 model
• Deployment dependencies ok
• Circular logical dependencies
• All the integration tests in one
module
• Referencing different bounded
contexts
• All DLLs would be available

64. View Model
Composition • Composing data from different
Bounded Contexts on front-end
• Suggested reading
• Mauro Servienti
• https://milestone.topics.it/
• The physician needs only to see the
prior applications
• Data shown for decision-support

65. Takeaways for the Team
▪ Regular Architectural Reviews
– continuous learning about subdomain boundaries
▪ Stable Abstraction Principle
– Define desired relationships between the modules
▪ Discover Logical Dependencies in Code Review
– 4+1 Model
▪ “You can always make things more cohesive”
– Kent Beck
Ella Fitzegerald –
«They Cant’t Take That Away From Me»

66. Book recommendation #5

70. Photos
• By !Original: MddVector: Wikimpan - Based on File:4+1 Architectural View Model.jpg by User:Mdd, CC BY-SA 3.0,
https://commons.wikimedia.org/w/index.php?curid=50144028
• https://unsplash.com/@renemolenkamp
• https://unsplash.com/@jancanty
• https://unsplash.com/@afafa
• https://unsplash.com/@walkator
• https://unsplash.com/@woutvanacker
• https://unsplash.com/@polarmermaid
• https://unsplash.com/@cdd20
• https://unsplash.com/@roaming_angel
• https://unsplash.com/@micheile
• https://unsplash.com/@patrickperkins
• https://unsplash.com/@melany_tuinfosalud
• https://unsplash.com/@timmossholder