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

Transforming Boundaries
There are an unlimited variety of situations and an unlimited number of options for drawing the
boundaries of 
BOUNDED CONTEXTS
. But typically the struggle is to balance some subset of the
following forces:
Favoring Larger B
OUNDED
 C
ONTEXTS
Flow between user tasks is smoother when more is handled with a unified model.

---

It is easier to understand one coherent model than two distinct ones plus mappings.
Translation between two models can be difficult (sometimes impossible).
Shared language fosters clear team communication.
Favoring Smaller B
OUNDED
 C
ONTEXTS
Communication overhead between developers is reduced.
C
ONTINUOUS INTEGRATION
is easier with smaller teams and code bases.
Larger contexts may call for more versatile abstract models, requiring skills that are in short
supply.
Different models can cater to special needs or encompass the jargon of specialized groups of
users, along with specialized dialects of the 
UBIQUITOUS LANGUAGE
.
Deep integration of functionality between different 
BOUNDED CONTEXTS
is impractical. Integration is
limited to those parts of one model that can be rigorously stated in terms of the other model, and
even this level of integration may take considerable effort. This makes sense when there will be a
small interface between two systems.
Accepting That Which We Cannot Change: Delineating the External
Systems
It is best to start with the easiest decisions. Some subsystems will clearly not be in any 
BOUNDED
CONTEXT
of the system under development. Examples would be major legacy systems that you are
not immediately replacing and external systems that provide services you'll need. You can identify
these immediately and prepare to segregate them from your design.
Here we must be careful about our assumptions. It is convenient to think of each of these systems
as constituting its own 
BOUNDED CONTEXT
, but most external systems only weakly meet the
definition. First, a 
BOUNDED CONTEXT
is defined by an 
intention
to unify the model within certain
boundaries. You may have control of maintenance of the legacy system, in which case you can
declare the intention, or the legacy team may be well coordinated and be carrying out an informal
form of 
CONTINUOUS INTEGRATION
, but don't take it for granted. Check into it, and if the
development is not well integrated, be particularly cautious. It is not unusual to find semantic
contradictions in different parts of such systems.