Bounded contexts keep large models usable
A content model with many objects requires an unsustainable level of coordination and can cause cascading changes. Instead, divide a large model into bounded contexts and define collaboration patterns between them.
Khononov, Vladik. Learning Domain-Driven Design. 1st edition, O’Reilly Media, Inc., 2021.
Bounded contexts are collections of one or more subdomains, worked on by a single team and unified by a common language. It’s best practice to start out with large contexts and divide as needed. Its size is a function of the model it encompasses, rather than a goal itself. They should not be junk drawers nor jacks of all trades.
There are three patterns of collaboration between contexts:
- Cooperation A. Partnership: Two way communication, ad-hoc informing each other, two way interpretation of a point of connection B. Shared kernel: Use when one thing has to be implemented in two different bounded contexts. Each team can modify it and has to work with everything in both bounded contexts. Limit this pattern because any change cascades quickly.
- Customer-supplier A. Conformist: The downstream context has to work with what the upstream team gives it. Use when the upstream context has more power. B. Anti-corruption layer: The downstream context can’t use information from the upstream context directly, and creates a layer to transform it into something it can use. Use when the upstream context has more power. C. Open-host service: The upstream context provides a “public” face that downstream contexts can come get what they need from. This interface doesn’t conform to the host context’s ubiquitous language.
- Separate ways: No integration, each context duplicates the functionality they need. Use when the benefits of coordination are outweighed by the difficulties of communication. Usually for generic subdomains that are easily handled in a couple of different ways. Do not use for core subdomains.