Aligning Bounded Contexts with Subdomains in Legacy Code - BuildStuff 2022

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.

Transcript

1. Aligning Bounded Contexts with Subdomains in Legacy Code BuildStuff 2022 Mufrid Krilic Domain-Driven Design Coach, CoWork, Norway www.cowork.no
2. CoWork - something to inspire you • No managers but full of leadership Tight-Loose-Tight aka TLT
3. Some light reading….
4. The Story Begins…. Story about a team dealing with a legacy system
5. The Legacy We Inherited • Product with 5+ years of development history • Heavily regulated healthcare market • The team that built the thing virtually disbanded
6. Business Case • Physicians prescribe medications • Integration with systems for prescription delivery in pharmacies • Focus on putting patient needs and safety on the top
7. The Legacy We Brought With Us • Mix of experienced and junior developers • Little to no experience in the specific domain
8. The Way Ahead Inner motivation • Making sense of the domain • Making sense of the code base Outer motivation • Providing value to the users and stakeholders
9. Making sense of the domain Use-Case: Prescribing pre-approved medication
14. Drawn with egon.io
16. Subdomains Where art thou?
18. Reducing the Cognitive Load • Legacy Code • Being able to navigate • …. and understand • Hidden boundaries in legacy code • Look for subdomains
19. Boundaries Where art thou?
20. Observable boundaries • Technical • Network • Containers • Organizational • Teams • Departments • Easily observable boundaries
21. Not so easily observable? • The “4+1” View Model of Software Architecture • Philippe Kruchten
22. https://bit.ly/4plus1Paper
23. Two Ways to Apply 4+1 Model • Establishing logical boundaries without distributing across other views • Distributing coherent logical components across other views
24. Logical Boundaries But Not Distributed • Highly cohesive logical units • Low coupling between logical units • Within the same repository, package unit or physical storage unit
25. Distributed Coherent Logical Units • Each logical unit maintains its responsibility for the bounded context it represents • We distribute instances of the same logical unit across process and physical views
26. Dependencies What can we learn about dependencies from 4+1 model?
27. Logical View Dependencies The reason for increased coupling • The amount of data that is passed across the boundaries
28. Cost of Dependencies in a Distributed System • Distributed logical dependencies • Across software and process views • Across the organization • Microservices?
29. “Fractal Geometry of Software Design” • “Cost of change is proportional to the distance between components”
30. Use Case Prescribing non-approved medication
37. Drawn with egon.io
38. Another Subdomain? Opportunity to reduce our cognitive load!
39. What Makes a Good Subdomain? • Pivotal Event? • NonApprovedMedicationPrescribed • Time-related activity • While waiting for approval the physician stops the prescription process
40. Drawn with egon.io
41. Bounded Contexts and 4+1 model
42. Traces of Bounded Contexts in Development View • Are there any established boundaries in the Development View? • Have there been attempts to isolate pieces of code before?
43. Development View Boundaries • .NET projects • Namespaces
44. Dependencies in Logical View • Analysis of • using statements • Import in Java • .NET project references • NuGet package references • Maven dependencies • Http calls to remote services • Event-based communication with remote services
45. Context Mapping Assumptions
46. We are assuming that Application Bounded Context exists in the Logical View and that the dependencies are towards Prescription Bounded Context.
47. Bounded Contexts in Legacy Code • Respect existing dependencies and relationships • Explicit decision on the amount of work needed to break things up
48. Decision Time
49. Application Bounded Context • Establish observable boundary • Visual Studio Solution • Java: Establish a namespace within the repository • Prescription Bounded Context remains as is • 1 week time-box • Summarize lessons learned regardless of the outcome
50. Tight Loose Tight • T: Agree on the goal and purpose • L: Find out how to get there • T: Learn from it
51. Logical Boundaries But Not Distributed • Highly cohesive logical units • Low coupling between logical units • Within the same repository, package unit or physical storage unit
52. Step One Establish Visual Studio Solution
53. Move existing .NET projects • Between solutions/folders within the same repository • git mv • Visual Studio Exclude/Include Project Code compiles and unit tests run
54. Integration tests? • Valuable enough feedback with unit tests only? • Integration/E2E tests • Harder to maintain • Can provide runtime feedback
55. Work on E2E tests? • Pros • Early feedback on bounded context/subdomain alignment • Cons • Considerable work needed just to get the tests running • Could slow down the feedback loop Focus on unit tests only at this stage
56. Step Two Cleaning up obsolete references
57. Made obsolete in step one • .NET project references • using statements Uncovers hidden dependencies
58. Classes and interfaces - Defined in Application BC - Referenced in Prescription BC
60. Step 3 Make E2E tests to run
61. The end of the story…. • Some E2E tests in Prescription context required code from Application context runtime • Why?
62. Valid business reason for Prescription BC to refer to Application BC - Beware of Circular Dependencies!
63. 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
64. Can we avoid circular dependencies? • All the integration tests in one module • Referencing different bounded contexts • All code (DLLs) would be available
66. Remembering 4+1 model • Deployment dependencies ok • Circular logical dependencies
68. Analyzing the needs behind the business requirement • User needs only to see prior applications • Show data as a decision support • Read Model • 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
69. From this….
70. To this….
71. View Model Composition • Suggested reading • Mauro Servienti • https://milestone.topics.it/ • Composing data from different Bounded Contexts on front-end
72. Takeaways For the team and for future endeavors
73. ▪ Regular Architectural Reviews ▪ Work Towards “Target Model” ▪ Discover Logical Dependencies in Code Review ▪ “You can always make things more cohesive” Ella Fitzegerald – «They Cant’t Take That Away From Me»
74. Regular Architectural Reviews • Weekly meetings • Continuous learning about boundaries • Another model to be found? • Different questions to be asked • e.g. during Domain Storytelling sessions
75. What is physician’s specialist field? What is patient’s diagnosis?
76. “Target Model” • Define a model that represents your understanding of the domain • How does Legacy system fits in? • Work towards the “Target Model” • Maintain the knowledge explicitly
77. Discover Logical Dependencies during Code Review • Pay particular attention to introduction of new references between namespaces, projects, packages • Question the intent behind • Requires discipline!
78. “You Can Always Make Things More Cohesive” • Kent Beck • DDDEU 2020 • What can we do? • Start by keeping things apart for a while…. • Until we have learned what they are
82. Team Techno Builders Follow us on GitHub! Software for robot programming https://education.lego.com/nb- no/downloads/spike-app/software https://education.lego.com/nb- no/downloads/spike-app/software
83. 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