Bounded Context
Architectural boundaries
- Definition
- Keep the naming of one area of the system separate from that of the other areas.
How does it work?
A system may consist of multiple areas (bounded contexts) that each have their own naming conventions (ubiquitous language). If this is the case then the names of one context should not be used in the other context. In stead a name should be mapped to another map when the data crosses the context boundary.
When should you use it?
- In a large-scale project with multiple teams, each with their own names and concepts
- When using a software library that may one day be replaced by another one
Common implementation techniques
- Data crossing a boundary is not a business entity but just a plain data object
- If class C1 from context C wants to talk to class D1 from context D, the system should provide an interface DI1. C1 then talks to DI1 and D1 implements DI1.
Problems
- Creating a boundary brings a significant amount of work.