Bounded Contexts: Manage the Understandability of Your Systems

From Parnas' paper in the 1970's to microservices in the 2010's, we've always used modularisation as a way to manage complexity in software. And yet, we still end up with big balls of mud. Technical separation alone isn’t enough. We’ve also tried separating into business domains, but that’s not enough either: software wants to be deeply interconnected, spanning different domains, and doesn’t respect those boundaries.

Bounded Contexts provide an alternative to splitting on domains or on technical modules. We can separate by looking at the semantics. The domain models that underlie our systems, the language that is being used, and the meanings of the terms. We can draw “understandability boundaries”: separations that look at how concepts in our system are understood together (or can be understood autonomously). If we organise the teams along the same lines, then team members will need to understand fewer concepts to be productive. Teams will need less coordination with other teams. Having better semantic boundaries lowers the cognitive load.

Doing this kind of work is not free. But in the 20 years since the concept was introduced in Domain-Driven Design, we’ve developed patterns and heuristics to guide us.

Transcript

1. Understandability of Your Systems Manage the Mathias Verraes verraes.net — @mathiasverraes Gien Verschatse gienverschatse.com — @selketjah
2. aardling.eu Software consulting for complex environments
3. Have you worked on a system that is hard to understand?
4. Abstraction is ✅ Good ✅ Bad
5. Lack of abstraction: Too much detail No organising principles Puts the burden on the reader
6. Good abstraction: Isolates a problem from other problems
7. Good abstraction: Evolves with the changing understanding of the problem
8. Bounded Context: A set of domain concepts, language, model, and abstractions that form a coherent whole, deliberately bounded.
9. Bounded Context: Understandability boundary
10. Domain How the business perceives itself Bounded Context How the devs organise models
13. Putaway Outbound Inbound Locations Locations Expedites Expedites Expedites
19. Consequences Sales, forecasting, quality control, staff management, customer support, shipment, deliveries, ... all heavily depend on each other.
20. Expedites & Staff mgmt touch many domains
21. Lots of local optimisations in code and by human operators
22. Putaway Outbound Inbound Efficiency Bounded Context Efficiency Expedites Staff Request availability Request availability
23. Ef fi ciency is now solved centrally
24. Components can’t decide on staff assignment They must request availability
25. Ef fi ciency model compares urgency of requests “Theory of Constraints as a Service”
26. The purpose of the system was rethought. The structure followed.
27. Putaway Outbound Inbound Location Bounded Context Request Location Request Location Locations
28. A Bounded Context for the business need as opposed to super fi cial domain boundaries
29. The new model is internally consistent self-contained decoupled
30. A Bounded Context represents a consistent model and language with an explicit boundary. Bounded Context as a boundary of language, meaning, and co-understandibility
31. Works both ways: working in the other contexts requires less knowledge of Ef fi ciency and vice versa
32. Research and development In biotech industry
33. WORKFLOWS Domains
34. SINGLE WORKFLOW Do 1 thing really well and improve how to do this
37. Consequences • Untestable code • Bugs • High complexity • Low understandability
38. How did we get there? People had abstracted them because on a super fi cial level they seemed similar
39. DEDICATED WORKFLOWS DNA building, strain building…
40. Involves a lot of liquid (DNA, strains, chemicals) transfers from one container to another AND evaluate whether or not you were successful
41. STAMP
 Single plate Source plate Destination plate
42. DILUTION Source plate Destination plate
43. COMPRESSION Source plate Destination plate
45. As a designer you need to know what to leave out and why
46. HITPICK You need to know what is inside the wells
48. We separate based on what something needs to know,
 and what it can afford not to know
49. 🤖ROBOTS!🤖 For liquid transfer
50. Different robots for different liquid transfers
51. Robots are assigned to departments
52. We need to tell the robots which liquid transfers they need to do = WORKLIST
54. Isolate the boundary between hard & software
55. DEDICATED WORKFLOWS For measuring success (QC)
56. INSTRUMENTS For measurement
57. Having each work fl ow do their own measurement is not optimal
59. Split according to the domain experts
60. TIME BUILDING SMALL PIECES OF DNA = 4 WEEKS BUILDING LARGE PIECES OF DNA = 1 WEEK
61. DNA BUILDING RETRY STEPS AFTER QUALITY CONTROL
62. SO WE NEED TO ADAPT OUR PLANNED LIQUID TRANSFERS We don’t need to adapt our liquid transfers for building large pieces of DNA.
64. Separate planning, executing, and analysis
65. DOMAIN (WORKFLOW) How the business perceives itself Bounded Context How the designers organise models
68. Costly, but: Compound effect
69. Thanks ❤ @selketjah @mathiasverraes aardling.eu
70. Thanks ❤ @selketjah @mathiasverraes aardling.eu