Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Aligning Bounded Contexts with Subdomains in Legacy Code

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.

Mufrid Krilic

December 02, 2021

More Decks by Mufrid Krilic

Other Decks in Programming


  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. Strategic DDD • Focusing on Core domain • Problem and

    solution space • Subdomains and Bounded Contexts • Linguistic boundaries • Ubiquitous Language • The two pillars of DDD
  4. Core Domain • The thing that distinguishes you from the

    competitors • “Not every part of the system will be well-designed” • Generic subdomain • Supporting subdomain
  5. Problem Space and Solution Space Problem space • Domain analysis

    to discover inherent Subdomains Solution space • Model your application accordingly in multiple Bounded Contexts
  6. The Two Pillars of DDD 1. Ubiquitous Language 2. Bounded

    Context Bounded contexts in your application are defined by linguistic boundaries
  7. Making Sense of the Problem Space • Aligning with the

    business • Reducing the translation effort • Ubiquitous Language
  8. Reducing the Cognitive Load • Legacy Code • Being able

    to navigate • …. and understand • Hidden boundaries in legacy code • Look for subdomains
  9. Observable boundaries • Technical • Network • Containers • Organizational

    • Teams • Departments • Easily observable boundaries
  10. Not so easily observable? • The “4+1” View Model of

    Software Architecture • Philippe Kruchten • https://bit.ly/4plus1Paper
  11. Logical View Dependencies The reason for increased coupling • The

    amount of data that is passed across the boundaries
  12. Cost of Dependencies in a Distributed System • Distributed logical

    dependencies • Across software and process views • Across the organization • Microservices
  13. Business Case • Physicians prescribe medications • Integration with systems

    for prescription delivery in pharmacies • Focus on putting patient needs and safety on the top
  14. Subdomains in Problem Space • Pivotal Event • NonApprovedMedicationPrescribed •

    Time-related activity • While waiting for approval the physician stops the prescription process
  15. Traces of Bounded Contexts in Development View • Are there

    any established boundaries in the Development View? • 4+1 Model • .NET projects • Namespaces
  16. 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
  17. DDD Context Mapping Downstream: depending on upstream Upstream: depended on

    downstream Conformist: Upstream model referenced directly in Downstream context
  18. Bounded Contexts in Legacy Code • Respect existing dependencies and

    relationships • Explicit decision on the amount of work needed to break things up
  19. 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
  20. Move existing .NET projects • Between solutions within the same

    repository • git mv • Exclude/Include Project Code compiles and unit tests run
  21. Integration tests? • Valuable enough feedback with unit tests only?

    • Integration/E2E tests • Harder to maintain • Can provide runtime feedback
  22. 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
  23. Made obsolete in step one • .NET project references •

    using statements Uncovers hidden dependencies
  24. Stable Abstraction Principle Packages that are maximally stable should be

    maximally abstract. • Extract common type definitions to a separate module
  25. The end of the story…. • Some E2E tests in

    Prescription context required DLLs from Application context • Why?
  26. 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
  27. 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
  28. 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
  29. 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»
  30. 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