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

Identify each model in play on the project and define its 
BOUNDED CONTEXT
. This includes
the implicit models of non-object-oriented subsystems. Name each 
BOUNDED CONTEXT
,
and make the names part of the 
UBIQUITOUS LANGUAGE
.
Describe the points of contact between the models, outlining explicit translation for any
communication and highlighting any sharing.

---

Map the
existing
terrain. Take up transformations later.
Within each 
BOUNDED CONTEXT
, you will have a coherent dialect of the 
UBIQUITOUS LANGUAGE
. The
names of the 
BOUNDED CONTEXTS
will themselves enter that 
LANGUAGE
so that you can speak
unambiguously about the model of any part of the design by making your 
CONTEXT
clear.
The 
MAP
does not have to be documented in any particular form. I find diagrams like the ones in
this chapter to be helpful in visualizing and communicating the map. Others may prefer a more
textual description or a different graphical representation. In some situaions, discussion among
teammates may be sufficient. The level of detail can vary according to need. Whatever form the
MAP
takes, it must be shared and understood by everyone on the project. It must provide a clear
name for each 
BOUNDED CONTEXT
, and it must make the points of contact and their natures clear.
The relationships between 
BOUNDED CONTEXTS
take many forms depending on both design issues
and project organizational issues. Later, this chapter will lay out various patterns of relationships
between 
CONTEXTS
that are effective in different situations, and that can provide terms to describe
the relationships you find in your own 
MAP
. Keeping in mind that the 
CONTEXT MAP
always
represents 
the situation as it stands
, the relationships you find may not fit these patterns initially.
If they fall close, you may wish to use the pattern name, but don't force it. Just describe the
relationships you find. Later you can begin to migrate toward more standardized relationships.
So, what do you do if you've discovered a splinter—a model that is completely entangled but
contains inconsistencies? Put a dragon on the map and finish describing everything. Then, with an
accurate global view, address the points of confusion. A minor splinter can be repaired, and
processes can be put in place to shore it up. If a relationship is vague, you can choose the nearest
pattern and move toward it. Your first order of business is to arrive at a clear 
CONTEXT MAP
, and
this may mean fixing real problems you have found. But don't let this necessary repair lead to
wholesale reorganization. Until you have an unambiguous 
CONTEXT MAP
that places all your work
into some 
BOUNDED CONTEXT
, with explicit relationships between all connected models, change only
the outright contradictions.
Once you have a coherent 
CONTEXT MAP
, you'll see things you want to change. You can make
considered changes to the organization of teams or to the design. Remember, don't change the
map until the change in reality is 
done
.