Aligning Bounded Contexts with Subdomains in Legacy Code - BuildStuff 2022

Slide 1

Slide 1 text

Aligning Bounded Contexts with Subdomains in Legacy Code BuildStuff 2022 Mufrid Krilic Domain-Driven Design Coach, CoWork, Norway www.cowork.no

Slide 2

Slide 2 text

CoWork - something to inspire you • No managers but full of leadership Tight-Loose-Tight aka TLT

Slide 3

Slide 3 text

Some light reading….

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

The Legacy We Inherited • Product with 5+ years of development history • Heavily regulated healthcare market • The team that built the thing virtually disbanded

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

The Legacy We Brought With Us • Mix of experienced and junior developers • Little to no experience in the specific domain

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

Making sense of the domain Use-Case: Prescribing pre-approved medication

Slide 10

Slide 10 text

No content

Slide 11

Slide 11 text

No content

Slide 12

Slide 12 text

No content

Slide 13

Slide 13 text

No content

Slide 14

Slide 14 text

Drawn with egon.io

Slide 15

Slide 15 text

No content

Slide 16

Slide 16 text

Subdomains Where art thou?

Slide 17

Slide 17 text

No content

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

Boundaries Where art thou?

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

Not so easily observable? • The “4+1” View Model of Software Architecture • Philippe Kruchten

Slide 22

Slide 22 text

https://bit.ly/4plus1Paper

Slide 23

Slide 23 text

Two Ways to Apply 4+1 Model • Establishing logical boundaries without distributing across other views • Distributing coherent logical components across other views

Slide 24

Slide 24 text

Logical Boundaries But Not Distributed • Highly cohesive logical units • Low coupling between logical units • Within the same repository, package unit or physical storage unit

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

Dependencies What can we learn about dependencies from 4+1 model?

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

“Fractal Geometry of Software Design” • “Cost of change is proportional to the distance between components”

Slide 30

Slide 30 text

Use Case Prescribing non-approved medication

Slide 31

Slide 31 text

No content

Slide 32

Slide 32 text

No content

Slide 33

Slide 33 text

No content

Slide 34

Slide 34 text

No content

Slide 35

Slide 35 text

No content

Slide 36

Slide 36 text

No content

Slide 37

Slide 37 text

Drawn with egon.io

Slide 38

Slide 38 text

Another Subdomain? Opportunity to reduce our cognitive load!

Slide 39

Slide 39 text

What Makes a Good Subdomain? • Pivotal Event? • NonApprovedMedicationPrescribed • Time-related activity • While waiting for approval the physician stops the prescription process

Slide 40

Slide 40 text

Drawn with egon.io

Slide 41

Slide 41 text

Bounded Contexts and 4+1 model

Slide 42

Slide 42 text

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?

Slide 43

Slide 43 text

Development View Boundaries • .NET projects • Namespaces

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

Context Mapping Assumptions

Slide 46

Slide 46 text

We are assuming that Application Bounded Context exists in the Logical View and that the dependencies are towards Prescription Bounded Context.

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

Decision Time

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

Tight Loose Tight • T: Agree on the goal and purpose • L: Find out how to get there • T: Learn from it

Slide 51

Slide 51 text

Logical Boundaries But Not Distributed • Highly cohesive logical units • Low coupling between logical units • Within the same repository, package unit or physical storage unit

Slide 52

Slide 52 text

Step One Establish Visual Studio Solution

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

Step Two Cleaning up obsolete references

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

No content

Slide 60

Slide 60 text

Step 3 Make E2E tests to run

Slide 61

Slide 61 text

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

Slide 62

Slide 62 text

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

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

Can we avoid circular dependencies? • All the integration tests in one module • Referencing different bounded contexts • All code (DLLs) would be available

Slide 65

Slide 65 text

No content

Slide 66

Slide 66 text

Remembering 4+1 model • Deployment dependencies ok • Circular logical dependencies

Slide 67

Slide 67 text

No content

Slide 68

Slide 68 text

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

Slide 69

Slide 69 text

From this….

Slide 70

Slide 70 text

To this….

Slide 71

Slide 71 text

View Model Composition • Suggested reading • Mauro Servienti • https://milestone.topics.it/ • Composing data from different Bounded Contexts on front-end

Slide 72

Slide 72 text

Takeaways For the team and for future endeavors

Slide 73

Slide 73 text

▪ 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»

Slide 74

Slide 74 text

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

Slide 75

Slide 75 text

What is physician’s specialist field? What is patient’s diagnosis?

Slide 76

Slide 76 text

“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

Slide 77

Slide 77 text

Discover Logical Dependencies during Code Review • Pay particular attention to introduction of new references between namespaces, projects, packages • Question the intent behind • Requires discipline!

Slide 78

Slide 78 text

“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

Slide 79

Slide 79 text

No content

Slide 80

Slide 80 text

No content

Slide 81

Slide 81 text

No content

Slide 82

Slide 82 text

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

Slide 83

Slide 83 text

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