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

4.
5.

---

Developers from either team take on the task of implementing the model (or adapting
existing code to be shared), working out details and making it function. If these developers
run into problems with the model, they reconvene the team from step 3 and participate in
any necessary revisions of the concepts.
5.
Developers of each team take on the task of integrating with the new 
SHARED KERNEL
.
6.
Remove translations that are no longer needed.
7.
At this point, you will have a very small 
SHARED KERNEL
, with a process in place to maintain it. In
subsequent project iterations, repeat steps 3 through 7 to share more. As the processes firm up
and the teams gain confidence, you can take on more complicated subdomains, multiple ones at
the same time, or subdomains that are in the 
CORE DOMAIN
.
A note: As you take on more domain-specific parts of the models, you may encounter cases where
the two models have conformed to the specialized jargon of different user communities. It is wise
to defer merging these into the 
SHARED KERNEL
unless a breakthrough to a deep model has
occurred, providing you with a language capable of superseding both specialized ones. An
advantage of a 
SHARED KERNEL
is that you can have some of the advantages of 
CONTINUOUS
INTEGRATION
while retaining some of the advantages of 
SEPARATE WAYS
.
Those are some guidelines for merging into a 
SHARED KERNEL
. Before going ahead, consider one
alternative that satisfies some of the needs addressed by this transformation. If one of the two
models is definitely preferred, consider shifting toward it without integrating. Instead of sharing
common subdomains, just systematically transfer full responsibility for those subdomains from one
BOUNDED CONTEXT
to the other by refactoring the applications to call on the model of the more
favored 
CONTEXT
, and making any enhancements that model needs. Without any ongoing
integration overhead, you have eliminated redundancy. Potentially (but not necessarily), the more
favored 
BOUNDED CONTEXT
could eventually take over completely, and you'll have created the same
effect as a merger. In the transition (which can be quite long or indefinite), this will have the usual
advantages and disadvantages of going 
SEPARATE WAYS
, and you have to weigh them against the
pros and cons of a 
SHARED KERNEL
.