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

The System Under Design
The software your project team is actually building is the 
system under design
. You can declare
BOUNDED CONTEXTS
within this zone and apply 
CONTINUOUS INTEGRATION
within each to keep them
unified. But how many should you have? What relationships should they have to each other? The
answers are less cut and dried than with the external systems because we have more freedom and
control.
It could be quite simple: a single 
BOUNDED CONTEXT
for the entire system under design. For
example, this would be a likely choice for a team of fewer than ten people working on highly
interrelated functionality.
As the team grows larger, 
CONTINUOUS INTEGRATION
may become difficult (although I have seen it
maintained for somewhat larger teams). You may look for a 
SHARED KERNEL
and break off relatively
independent sets of functionality into separate 
BOUNDED CONTEXTS
, each with fewer than ten
people. If all of the dependencies between two of these go in one direction, you could set up
CUSTOMER/SUPPLIER DEVELOPMENT TEAMS
.
You may recognize that the mindsets of two groups are so different that their modeling efforts
constantly clash. It may be that they actually need quite different things from the model, it may
be just a difference in background knowledge, or it may be a result of the management structure
the project is embedded in. If the cause of the clash is something you can't change, or don't want
to change, you may choose to allow the models to go 
SEPARATE WAYS
. Where integration is needed,
a translation layer can be developed and maintained jointly by the two teams as the single point of
CONTINUOUS INTEGRATION
. This is in contrast with integration with external systems, where the
ANTICORRUPTION LAYER
typically has to accommodate the other system as is and without much
support from the other side.
Generally speaking, there is a correspondence of one team per 
BOUNDED CONTEXT
. One team can
maintain multiple 
BOUNDED CONTEXTS
, but it is hard (though not impossible) for multiple teams to
work on one together.