Bounded Context: Problem or Solution?

Bounded contexts play a central role in domain-driven design discussions. They are considered a promising solution for modularizing systems, whether as deployment monoliths or microservices. However, applying them in practice comes with challenges: it is often difficult to divide a domain into bounded contexts. Moreover, the concept is not easy to grasp. On the one hand, it represents the division of a software system into modules; on the other hand, it aims to separate different domain languages within a domain. Additionally, a bounded context is often regarded as a team. How can all of this be reconciled, and how can one work successfully with it in practice? This talk explains what bounded contexts are and then explores these challenges, showing how DDD can make projects even more successful.

Transcript

1. Bounded Context – Problem or Solution? Eberhard Wolff Head of Architecture https://swaglab.rocks/ https://ewolff.com/
2. Why is this Talk? •Bounded Context seems simple …but it’s not. •Goal: Clear up the confusion.
3. Bounded Context Bounds Domain Model i.e. Code Ubiquitous Language
4. Order Process Invoicing Process Bounded Context Example Invoicing VAT Shipping Tracking Delivery Accept order Shopping Cart
5. Order Process Invoicing Process Bounded Context 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
6. Why is Bounded Context so Important? •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
7. Bounded Context: Three Implications Ubiquitous Language Domain Model Teams
8. Order Process Invoicing Process Bounded Context 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 Ubiquitous Language? …or just a domain model? Teams?
9. Bounded Context solves three problems…
10. Bounded Context solves three problems… …and that might be a problem.
11. Is there a simpler way?
12. Bounded Context Ubiquitous Language
13. Ubiquitous Language Definition •One language …in written language …in spoken language …in code
14. Ubiquitous Language & Bounded Context Within each Bounded Context, you will have a coherent dialect of the Ubiquitous Language. Eric Evans Domain-driven Design: Tackling Complexity in the Heart of Software
15. Ubiquitous Language Definition •Project have their own language •You can identify a project by an expression of its language.
16. Ubiquitous Language: More Examples •Code implements unambiguous logic. •Designing these rules is the main challenge. •Prerequisite: Find the Ubiquitous Language that captures the central business ideas. •Often terms in natural language are ambiguous. •Bounded Contexts helps: Terms might be unambiguous in a Bounded Context. •There are many non-trivial examples.
17. Who is a Customer of a Hotel? Invoicing SWAGLab GmbH Bei den Mühren 1 20457 Hamburg Registration Eberhard Wolff Kaiserslautern Single person Payment Eberhard Wolff (Card holder)
18. Invoice at a Major Hotel Chain… This doesn‘t work because there are all these IT systems we need to integrate. Where did you do the booking? Your website This my private address. Can I get an invoice with the correct address as provide in the booking?
19. Who is a Customer of a Hotel? Eberhard Wolff SWAGLab GmbH Bei den Mühren 1 20457 Hamburg
20. Ubiquitous Language: Concrete Advice •Very important concept •Good tool to analyze and understand domains •Great to understand different concepts in a domain •There is not just one ubiquitous language …therefore, there can’t be just one domain model …and business entities are complicated (customer)
21. Bounded Context Domain Model
22. Domain Model Definition •“Domain Model” sound like a conceptual model …or a diagram? •But really it is about a “model expressed in software” i.e. working code that implements business logic •Implemented using e.g. Tactical Design
23. Ubiquitous Language -> Domain Model? Invoicing SWAGLab GmbH Bei den Mühren 1 20457 Hamburg Registration Eberhard Wolff Kaiserslautern Single person Payment Eberhard Wolff (Card holder) A different Ubiquitous Language should be implemented by a different Domain Model Helpful?
24. Public Information Changeable Internals Module Information hiding: Internals can be changed freely because public information remain unchanged.
25. Interfaces Code / systems Microservice
26. Public Methods Instance Variables Class
27. Interfaces Code / systems Team
28. Domain Model vs Modul •Modul is more general (technical or business) •Modules can form a hierarchy. …unlike Bounded Contexts. •Core to really implement complex systems
29. Domain Model vs Ubiquituous Language •Different ubiquitous languages are a very strong hint to separate things in software, too. •Main benefit of Bounded Context for software architecture. •Should there be exceptions?
30. Modules with Shared Domain Models Registration Bounded Context Module Microservice 1 First part of registration Microservice 2 Second part of registration A shared domain model hints a tight coupling. A sound example will have microservices with different bounded contexts.
31. Modules with Shared Domain Models Registration Bounded Context Module Microservice Communication to other services Frontend Logic Separate technical modules inside a Bounded Context are natural. Might use ports & adapters instead.
32. Modules with Shared Domain Models •Sharing a domain model but separating parts of the domain logic leads to tight coupling. •Should be obvious, but it’s not. •Sharing a domain model and separating technical parts makes lots of sense.
33. Public Information = Data Changeable Internals = Data Customer Module? Information hiding doesn’t really work if the public information is just an interface to some data. The General Universal Customer Model might be too complex.
34. Public Information: Interface to create an invoice Changeable Internals: How invoice is generated Functionality: Natural Modules Information hiding works only if the public information is an interface to functionality with hidden implementation.
35. Easier Alternative: Just Modules •Don’t talk about Ubiquitous Language •Ask people to organize a system by functionality. •Results very similar. •Might be the easier approach.
36. Domain Model: Concrete Advice •Focus on: Organize the architecture by functionality not by data! •Core value of Bounded Context for architectures •Don’t get caught up in the details of the Bounded Context definition!
37. Bounded Context Teams
38. Strategic Domain-driven Design •Relations between Bounded Contexts somehow become relations between teams.
39. Example: Customer / Supplier •What if the successful implementation of an important bounded context depends on another bounded context? •Team have customer or supplier role. •Customer influences planning of supplier. •Important bounded context -> customer role •IMHO a clearly a valid approach!
43. https://software-architektur.tv/2021/08/27/folge72.html
44. Too Complicated •Three relations •Nine collaboration patterns •Mix pure organization (e.g. Customer / Supplier) and pure technical approaches (e.g. Published Language) •Hard to fully grasp
45. Inverse Conway
46. Inverse Conway Order Process Delivery Invoicing
47. Inverse Conway Order Process Delivery Invoicing Modul Modul Modul
48. More than Bounded Context •Teams are not just organized by Bounded Context •E.g. infrastructure teams
49. Team = Bounded Context? •Inverse Conway is too simplistic •One team can work on more than one BC •It might be fine for multiple teams to work on one Bounded Context. –Might be needed due to deadlines –Might not impact productivity too much because things are separated i.e. by technology.
50. Beyond Strategic Design •We need a more general model …that should also be simpler.
51. Team Topologies Stream-aligned team Platform team Enabling team Complicated Subsystem team XaaS Collaboration Facilitating XaaS
52. https://software-architektur.tv/2024/04/18/folge213.html
53. Conclusion
54. Bounded Context Talks about … Ubiquituous Language: Useful Domain Model: Consider general module concept instead …and build modules by functionality Teams: Strategic Design is complex and not very powerful Consider Team Topologies instead!
55. https://software-architektur.tv/2024/06/14/episode220.html
56. WIR SUCHEN MITGESTALTER:INNEN swaglab.rocks/karriere
57. TRINK EINEN VIRTUELLEN KAFFEE MIT MIR! https://calendly.com/eberhard-wolff-swaglab/
58. Download here! Send email to oop2025@ewolff.com Slides + Sample Microservices Book DE / EN + Sample Practical Microservices DE/EN + Sample of Continuous Delivery Book DE Powered by Amazon Lambda & Microservices Email address logged for 14 days, wrong addressed emails handled manually