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

Relationships Between B
OUNDED
 C
ONTEXTS
The following patterns cover a range of strategies for relating two models that can be composed to
encompass an entire enterprise. These patterns serve the dual purpose of providing targets for
successfully organizing development work, and supplying vocabulary for describing the existing
organization.
An existing relationship may, by chance or by design, fall near one of these patterns, in which case
you can describe it using that term, variations duly noted. Then, with each small design change,
the relationship can be drawn closer to the chosen pattern.
On the other hand, you may find that an existing relationship is muddled or overcomplicated.
Some reorganization might be necessary just to make an unambiguous 
CONTEXT MAP
possible. In
this situation, or any situation in which you are considering reorganization, these patterns present
a range of choices that are favored in different circumstances. Prominent variables include the
level of control you have over the other model, the level and type of cooperation between teams,
and the degree of integration of features and data.
The following set of patterns covers some of the most common and important cases, which should
give you a good idea of how to approach other cases. A crack team working closely on a tightly
integrated product can deploy a large unified model. The need to serve different user communities
or a limitation on the coordination abilities of the team might lead to a 
SHARED KERNEL
or
CUSTOMER/SUPPLIER
relationships. Sometimes a good hard look at the requirements reveals that
integration is not essential and it is best for systems to go their 
SEPARATE WAYS
. And, of course,
most projects have to integrate to some degree with legacy and external systems, which can lead
to 
OPEN HOST SERVICES
or 
ANTICORRUPTION LAYERS
.
[ Team LiB ]

---

[ Team LiB ]
Shared Kernel
When functional integration is limited, the overhead of 
CONTINUOUS INTEGRATION
may be deemed
too high. This may especially be true when the teams do not have the skill or the political
organization to maintain continuous integration, or when a single team is simply too big and
unwieldy. So separate 
BOUNDED CONTEXTS
might be defined and multiple teams formed.