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

Bounded Context: Problem or Solution?

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.

Eberhard Wolff

February 05, 2025
Tweet

More Decks by Eberhard Wolff

Other Decks in Technology

Transcript

  1. Bounded Context – Problem or Solution? Eberhard Wolff Head of

    Architecture https://swaglab.rocks/ https://ewolff.com/
  2. 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
  3. 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
  4. 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?
  5. 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
  6. Ubiquitous Language Definition •Project have their own language •You can

    identify a project by an expression of its language.
  7. 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.
  8. 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)
  9. 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?
  10. Who is a Customer of a Hotel? Eberhard Wolff SWAGLab

    GmbH Bei den Mühren 1 20457 Hamburg
  11. 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)
  12. 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
  13. 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?
  14. Public Information Changeable Internals Module Information hiding: Internals can be

    changed freely because public information remain unchanged.
  15. 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
  16. 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?
  17. 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.
  18. 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.
  19. 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.
  20. 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.
  21. 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.
  22. 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.
  23. 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!
  24. 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!
  25. 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
  26. More than Bounded Context •Teams are not just organized by

    Bounded Context •E.g. infrastructure teams
  27. 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.
  28. 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!
  29. Download here! Send email to [email protected] 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