Aligning Bounded Contexts with Subdomains in Legacy Code

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 shows 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 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.

Transcript

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