Models vs Bounded Contexts for Domain Modularizati...

Bounded Contexts are often considered the go-to solution for modularizing business logic – a key challenge in building maintainable systems. But in practice, the concept of a “Bounded Context” is complex and not always easy to implement.

In this talk, we explore how models can serve as a practical tool for identifying the different parts of a domain. While Domain-Driven Design highlights models—placing them at the heart of Bounded Contexts—they can also be valuable beyond that. Especially when combined with concepts like modules or abstract data types, models offer a powerful approach to structuring domain logic.

Transcript

1. Models vs Bounded Contexts for Domain Modularization Eberhard Wolff Head of Architecture https://swaglab.rocks/ https://ewolff.com/
2. Why is this Talk? • Coarse-grained modularization is very important. • Can lead to more or less independent teams. • Can lead to great or disastrous microservices. • Bounded Context: The solution? • I am not so sure.
3. Models
4. What Is a Model? • Wikipedia: “informative representation of an object, person or system” “serves as a substitute for the original”
5. Map: A Model – The Blue Book Tabula Rogeriana by Muhammad al-Idrisi, 1154
6. All models are wrong, but some are useful. George Box
7. Are We Really Building a Model? • Code does not “serve as a substitute for the original” • If code says the laptop costs 42€, then it does. • Code defines what a bank accounts is. • I.e. code defines reality.
8. What Kinds of Models Can We Come Up With?
9. Model Data https://chatgpt.com/share/691db786-28a4-800f-9701-4314944f6c93
10. Order Process Invoicing Process Model Data Shipping Customer Product Lots of dependencies Low autonomy
11. Data & Autonomy • Lots of projects really struggle with a shared data model. • Implemented in the database • Limits autonomy • Hard to eliminate
12. Order Process Invoicing Process Model Data Shipping Customer Product Customer: SWAGLab GmbH, Hamburg SWAGLab GmbH orders a laptop to be delivered to me Customer: Eberhard, Kaiserslautern
13. Data & Consistency • For some reason, people are afraid of inconsistencies for these architectures. • Even though there is not necessarily a copy of the same data. • Even though so many struggle with shared databases. • Even though current system are not that consistent, either.
14. Data & Consistency • If all functionalities use the same data… …and consistency is more important than autonomy, use a shared data model. • Architecture = decisions about trade-offs
15. Models as Modules
16. http://cseweb.ucsd.edu/~wgg/CSE218/Parnas-IFIP71-information-distribution.PDF https://blog.acolyer.org/2016/10/17/information-distribution-aspects-of-design-methodology/
17. Information Distribution Aspects • Modules can be changed freely • …if they still meet expectations from other modules. • Other modules will use all information about a module.
18. Information Distribution Aspects • Information hiding: Hide as much information as possible • Less information leaks to other modules • Result: Modules easier to change • Still valid, fundamental concept
19. Public Information Changeable Internals Module
20. How to Find Modules • Define which functionality goes where. • Then think about the data.
21. Public Information Changeable Internals Module Functionality Data
22. Order Process Invoicing Process Module Example Invoicing VAT Shipping Tracking Delivery Accept order Shopping Cart We can discuss what goes where.
23. But data is implementation? Order Process Invoicing Process Module Example Customer e.g. billing address Product e.g. price Shipping Customer e.g. shipping address Product e.g. size Product e.g. marketing information Customer e.g. product preferences Different data = different modules?
24. How to Find Modules • Define which functionality goes where. • We need heuristics for this. • IMHO one of the biggest challenges in architecture.
25. Bounded Context
26. Bounded Context Bounds Domain Model i.e. Code Ubiquitous Language
27. Bounded Context • Core pattern of Domain-driven Design • Limits the context of a ubiquitous language • Central to structuring systems into domain models • Also defines the scope of a team
28. Bounded Context: Three Implications Ubiquitous Language Domain Model Teams
29. Bounded Context solves three problems…
30. Bounded Context solves three problems… …and that might be a problem.
31. A Closer Look Ubiquitous Language Domain Model Teams Provides a good domain architecture
32. Ubiquitous Language • Great for requirements engineering • “Customer” might be different things depending who you talk to.
33. Ubiquitous Language • Different ubiquitous languages probably translate to different models. • So they help to find good models. • But the language is similar to data. • We should focus on functionality. • Data should be a concern later on.
34. SWAGLab Gmbh, Hamburg Order Process Invoicing Process Ubiquituous Language as a Heuristic Customer e.g. billing address Product e.g. price Shipping Customer e.g. shipping address Product e.g. size Product e.g. marketing information Customer e.g. product preferences Ubiquitous Language Eberhard, Kaiserslautern Different Language
35. But they seem to share a ubiquitous language? We found great models! Yes? So why are they separate bounded contexts? Confused by Bounded Context = Model + Ubiquitous Language
36. https://software-architektur.tv/2025/04/25/folge261.html
37. A Closer Look Ubiquitous Language Domain Model Teams Helps to find separate models Helps with requirements engineering. Provides a good domain architecture Too close to data?
38. Teams • Not all teams work on business logic
39. Team Topologies • Stream-aligned teams: Aligned with one stream of changes (probably business logic) • Platform teams: provide a platform as an internal product • Enabling teams: enable other teams • Complex subsystem team: Provide e.g. a complex algorithm
40. Can More Than One Team Work on a Model? • Sometimes more than one team works on a model. • E.g. because of a deadline • Sometimes a (very) bad idea • Sometimes works • Maybe there are somewhat independent parts of the model. • Maybe there are technical splits (front- / backend)
41. Do Teams Work on Different Models? • Team Topologies introduces Fracture Planes • E.g. Bounded Context = separate models • Other Fracture Planes: • Technology • Location • Personas • ….
42. https://software-architektur.tv/2022/07/01/folge125.html
43. A Closer Look Ubiquitous Language Domain Model Teams Helps to find separate models Helps with requirements engineering. Not all teams deal with business logic. Team Topologies: Platform teams, enabling teams, complex subsystem team Team Topologies Fracture planes Teams working on business logic might be separated by technology, location… Provides a good domain architecture
44. Event Storming
45. What is Event Storming? • Event in the past • At least noun + verb • Verb in past tense • Write event on orange sticky Order accepted
46. Phase: Chaotic Exploration • Create as many events as possible
47. Phase: Enforce the timeline
48. Phase: Enforce the timeline
49. Phase: Identify Swim Lanes • Parallel activities Swimlane Invoicing Swimlane Delivery
50. Phase: Identify Pivotal Events • Afterwards the world is different Order accepted Parcel left warehouse Swimlane Invoicing Swimlane Delivery
51. Parcel left warehouse Identify Candidates for Bounded Contexts • Areas between swim lanes and pivotal events are good candidates for Bounded Contexts Swimlane Delivery Order accepted Swimlane Invoicing
52. Identify Candidates for Bounded Contexts Invoicing Delivery Process Order Processing Should this also handle reimbursements? Should this also handle returns? Should the delivery process also handle the prediction of the delivery time?
53. Event Storming • Event storming helps to identify models… …if they are separated by time (pivotal events) …or independent because of parallel work (swim lanes) • Sometimes that doesn’t help to figure out which functionality goes where.
54. Abstract Data Types & Test-driven Development
55. Abstract Data Types Stack<T> push(T) pop : T empty : boolean after: empty = false precondition: empty = false push(a) push(b) pop -> b pop -> a Defines semantics Abstracts from implementation Array LinkedList
56. Abstract Data Types BankAccount deposit(Money) withdraw(Money) balance : Money after: balance + amount Defines semantics Abstracts from implementation Balance stored in a variable Balance calculated based on deposits / withdrawls before: balance> amount
57. Test-driven Development BankAccount account = new BankAccount assert account.balance == 0€ account.deposit(42€) assert account.balance == 42€ Then write the implementation. Come up with data structures. Write the test
58. Abstract Data Types & Test-driven Design • ADTs and TDD teach to focus on functionalities, interface, API • ADTs and TDD ignore implementation and therefore data. • We need this thinking for coarse-grained level modules, too.
59. Conclusion
60. Conclusion • Modeling data is not the core problem. • Which functionality goes where is a very important question in architecture. • We can only provide heuristics for this question.
61. Heuristics • Bounded Context: Heuristic Ubiquitous Language IMHO hard to understand and alien for many Too close to data • Event Storming: Easy to do, great collaboration …but leaves some questions unanswered • Abstract Data Types / Test-driven Development help to think about the interface.
62. https://software-architektur.tv/2025/04/25/folge261.html
63. WIR SUCHEN MITGESTALTER:INNEN swaglab.rocks/karriere
64. DRINK A VIRTUAL COFFEE WITH ME! Eberhard Wolff Head of Architecture https://swaglab.rocks/ https://ewolff.com/ https://calendly.com/eberhard-wolff-swaglab/
65. Slides + more Powered by Amazon Lambda Email address logged for 14 days, wrong addressed emails handled manually Scan QR code or send email to sag2025@ewolff.com