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

Uncoordinated teams working on closely related applications can go racing forward for
a while, but what they produce may not fit together. They can end up spending more on
translation layers and retrofitting than they would have on 
CONTINUOUS INTEGRATION
 in
the first place, meanwhile duplicating effort and losing the benefits of a common
UBIQUITOUS LANGUAGE
.
On many projects I've seen the infrastructure layer shared among teams that worked largely
independently. An analogy to this can work well within the domain as well. It may be too much
overhead to fully synchronize the entire model and code base, but a carefully selected subset can
provide much of the benefit for less cost.
Therefore:
Designate some subset of the domain model that the two teams agree to share. Of
course this includes, along with this subset of the model, the subset of code or of the
database design associated with that part of the model. This explicitly shared stuff has
special status, and shouldn't be changed without consultation with the other team.
Integrate a functional system frequently, but somewhat less often than the pace of
CONTINUOUS INTEGRATION
 within the teams. At these integrations, run the tests of both
teams.
It is a careful balance. The 
SHARED KERNEL
cannot be changed as freely as other parts of the
design. Decisions involve consultation with another team. Automated test suites must be

---

integrated because all tests of both teams must pass when changes are made. Usually, teams
make changes on separate copies of the 
KERNEL
, integrating with the other team at intervals. (For
example, on a team that 
CONTINUOUSLY INTEGRATES
daily or better, the 
KERNEL
merger might be
weekly.) Regardless of when code integration is scheduled, the sooner both teams talk about the
changes, the better.
The 
SHARED KERNEL
is often the 
CORE DOMAIN
, some set of 
GENERIC SUBDOMAINS
, or both (see
Chapter 15), but it can be any part of the model that is needed by both teams. The goal is to
reduce duplication (but not to eliminate it, as would be the case if there were just one 
BOUNDED
CONTEXT
) and make integration between the two subsystems relatively easy.
[ Team LiB ]

---

[ Team LiB ]