Domain-Driven Design: Tackling Complexity in the Heart of Software

Team Decision or Higher
First, teams have to make decisions about where to define 
BOUNDED CONTEXTS
and what sort of
relationships to have between them. 
Teams
have to make these decisions, or at least the decisions
have to be propagated to the entire team and understood by everyone. Infact, such decisions
often involve agreements beyond your own team. On the merits, decisions about whether to
expand or to partition 
BOUNDED CONTEXTS
should be based on the cost-benefit trade-off between
the value of independent team action and the value of direct and rich integration. In practice,
political relationships between teams often determine how systems are integrated. A technically
advantageous unification may be impossible because of reporting structure. Management may
dictate an unwieldy merger. You won't always get what you want, but at least you may be able to
assess and communicate something of the cost incurred, and take steps to mitigate it. Start with a
realistic 
CONTEXT MAP
and be pragmatic in choosing transformations.
Putting Ourselves in Context
When we are working on a software project, we are interested primarily in the parts of the system
our team is changing (the "system under design") and secondarily in the systems it will
communicate with. In a typical case, the system under design is going to get carved into one or
two 
BOUNDED CONTEXTS
that the main development teams will be working on, perhaps with another
CONTEXT
or two in a supporting role. In addition to that are the relationships between these
CONTEXTS
and the external systems. This is a simple, typical view, to give some rough expectation
for what you are likely to encounter.
We really are 
part of
that primary 
CONTEXT
we are working in, and that is bound to be reflected in
our 
CONTEXT MAP
. This isn't a problem if we are aware of the bias and are mindful of when we step
outside the limits of that MAP's applicability.