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

Institute a process of merging all code and other implementation artifacts frequently,
with automated tests to flag fragmentation quickly. Relentlessly exercise the
UBIQUITOUS LANGUAGE
 to hammer out a shared view of the model as the concepts evolve
in different people's heads
.
Finally, do not make the job any bigger than it has to be. C
ONTINUOUS INTEGRATION
is essential only
within a 
BOUNDED CONTEXT
. Design issues involving neighboring 
CONTEXTS
, including translation,
don't have to be dealt with at the same pace.
C
ONTINUOUS INTEGRATION
would be applied within any individual 
BOUNDED CONTEXT
that is larger
than a two-person task. It maintains the integrity of that single model. When multiple 
BOUNDED
CONTEXTS
coexist, you have to decide on their relationships and design any necessary interfaces. .
. .
[ Team LiB ]

---

[ Team LiB ]
Context Map
An individual BOUNDED CONTEXT still does not provide a global view. The context of other models
may still be vague and in flux.
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.
Code reuse between 
BOUNDED CONTEXTS
is a hazard to be avoided. Integration of functionality and
data must go through a translation. You can reduce confusion by defining the relationship between
the different contexts and creating a global view of all the model contexts on the project.
A 
CONTEXT MAP
is in the overlap between project management and software design. The natural
course of events is for the boundaries to follow the contours of team organization. People who
work closely will naturally share a model context. People on different teams, or those that don't
talk, even if they are on the same team, will split off into different contexts. Physical office space
can have an impact too, as team members on opposite ends of a building—not to mention
different cities—will probably diverge without extra integration effort. Most project managers
intuitively recognize these factors and broadly organize teams around subsystems. But the
interrelationship between team organization and software model and design is still not prominent
enough. Both managers and team members need a clear view into the ongoing conceptual
subdivision of the software model and design.
Therefore: