I’ve been spending a ton of time thinking about DDD, systems, components, SOA, and all that junk. Coming around to the concept of bounded context.
Here are some of the descriptions of bounded context.
Wikipedia says (emphasis mine):
Explicitly set boundaries in terms of team organization, usage within specific parts of the application, and physical manifestations such as code bases and database schemas. Keep the model strictly consistent within these bounds, but don’t be distracted or confused by issues outside.
ThinkDDD says (emphasis mine):
A Bounded Context can be considered as a miniature application, containing it’s own Domain, own code and persistence mechanisms.
Within a Bounded Context, there should be logical consistency, each Bounded Context should be independent of any other Bounded Context.
Communication to and from a Bounded Context is done via a Context Map
Digging into what a Context Map is, Domain-Drive Design Community says (emphasis mine):
Problem: People on other teams won’t be very aware of the Context bounds and will unknowingly make changes that blur the edges or complicate the interconnections. When connections must be made between different contexts, they tend to bleed into each other.
Solution: Identify each model in play on the project and define its Bounded Context. This includes the implicit models of nonobject-oriented subsystems. Name each Bounded Context, and make the names part of the Ubiquitous Language.
An article on devlicio.us by Jak Charlton has this little gem in one of the comments:
Apart from the benefit of logical and physical separation, this allows different teams to work on different Contexts, with little impact on each other until a Context Map needs to change.