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

Merging C
ONTEXTS
: S
EPARATE
 W
AYS
 
 S
HARED
 K
ERNEL
Translation overhead is too high. Duplication is too obvious. There are many motivations for
merging 
BOUNDED CONTEXTS
. This is hard to do. It's not too late, but it takes some patience.
Even if your eventual goal is to merge completely to a single 
CONTEXT
with 
CONTINUOUS
INTEGRATION
, start by moving to a 
SHARED KERNEL
.
Evaluate the initial situation. Be sure that the two 
CONTEXTS
are indeed internally unified
before beginning to unify them with each other.
1.
Set up the process. You'll need to decide how the code will be shared and what the module
naming conventions will be. There must be at least weekly integration of the 
SHARED KERNEL
code. And it must have a test suite. Set this up before developing any shared code. (The test
suite will be empty, so it should be easy to pass!)
2.
Choose some small subdomain to start with—something duplicated in both 
CONTEXTS
, but 
not
part of the 
CORE DOMAIN
. This first merger is going to establish the process, so it is best to
use something simple and relatively generic or noncritical. Examine the integrations and
translations that already exist. Choosing something that is being translated has the
advantage of starting out with a proven translation, plus you'll be thinning your translation
layer.
3.
At this point, you have two models that address the same subdomain. There are basically three
approaches to merging. You can choose one model and refactor the other 
CONTEXT
to be
compatible. This decision can be made wholesale, setting the intention of systematically replacing
one 
CONTEXT'S
model and retaining the coherence of a model that was developed as a unit. Or you
can choose one piece at a time, presumably ending up with the best of both (but taking care not
to end up with a jumble).
The third option is to find a new model, presumably deeper than either of the originals, capable of
assuming the responsibilities of both.
Form a group of two to four developers, drawn from both teams, to work out a shared model
for the subdomain. Regardless of how the model is derived, it must be ironed out in detail.
This includes the hard work of identifying synonyms and mapping any terms that are not
already being translated. This joint team outlines a basic set of tests for the model.