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

Deployment
Coordinating the packaging and deployment of complex systems is one of those boring tasks that
are almost always a lot harder than they look. The choice of 
BOUNDED CONTEXT
strategy has an
impact on the deployment. For example, when 
CUSTOMER/SUPPLIER TEAMS
deploy new versions,
they have to coordinate with each other to release versions that have been tested together. Both
code and data migrations have to work in these combinations. In a distributed system, it may help
to keep the translation layers between 
CONTEXTS
together within a single process, so that you don't
have multiple versions coexisting.
Even deployment of the components of a single 
BOUNDED CONTEXT
can be challenging when data
migration takes time or when distributed systems can't be updated instantaneously, resulting in
two versions of the code and data coexisting.
Many technical considerations come into play depending on the deployment environment and
technology. But the 
BOUNDED CONTEXT
relationships can point you toward the hot spots. The
translation interfaces have been marked out.

---

The feasibility of a deployment plan should feed back into the drawing of the 
CONTEXT
boundaries.
When two 
CONTEXTS
are bridged by a translation layer, one 
CONTEXT
can be updated just so a new
translation layer provides the same interface to the other 
CONTEXT
. A 
SHARED KERNEL
imposes a
much greater burden of coordination, not just in development but also in deployment. S
EPARATE
WAYS
can make life much simpler.
The Trade-off
To sum up these guidelines, there is a range of strategies for unifying or integrating models. In
general terms, you will trade off the benefits of seamless integration of functionality against the
additional effort of coordination and communication. You trade more independent action against
smoother communication. More ambitious unification requires control over the design of the
subsystems involved.