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

Route Specifications
into
the 
Routing Service
and check the returned 
Itinerary
.
Model contexts always exist, but without conscious attention they may overlap and fluctuate. By
explicitly defining 
BOUNDED CONTEXTS
and a 
CONTEXT MAP
, your team can begin to direct the process
of unifying models and connecting distinct ones.
Testing at the C
ONTEXT
 Boundaries
Contact points with other 
BOUNDED CONTEXTS
are particularly important to test. Tests help
compensate for the subtleties of translation and the lower level of communication that typically
exist at boundaries. They can act as a valuable early warning system, especially reassuring in
cases where you depend on the details of a model you don't control.
Organizing and Documenting C
ONTEXT
 M
APS
There are only two important points here:
The 
BOUNDED CONTEXTS
should have names so that you can talk about them. Those names
should enter the 
UBIQUITOUS LANGUAGE
of the team.
1.
Everyone has to know where the boundaries lie, and be able to recognize the CONTEXT of
any piece of code or any situation.
2.
The second requirement could be met in many ways depending on the culture of the team. Once
the 
BOUNDED CONTEXTS
have been defined, it comes naturally to segregate the code of different
CONTEXTS
into different 
MODULES
, which leaves the question of how to keep track of which 
MODULE
belongs in which 
CONTEXT
. A naming convention might be used to indicate this, or any other
mechanism that is easy and avoids confusion.
Equally important is communicating the conceptual boundaries in such a way that everyone on the
team understands them the same way. For this communication purpose, I like informal diagrams

---

like the ones in the example. More rigorous diagrams or textual lists could be made, showing all
packages in each 
CONTEXT
, along with the points of contact and the mechanisms responsible for
connecting and translating. Some teams will be more comfortable with this approach, while others
will get by fine based on spoken agreement and lots of discussion.
In any case, working the 
CONTEXT MAP
into discussions is essential if the names are to enter the
UBIQUITOUS LANGUAGE
. Don't say, "George's team's stuff is changing, so we're going to have to
change our stuff that talks to it." Say instead, "The 
Transport Network
model is changing, so we're
going to have to change the 
translator
for the 
Booking context
."
[ Team LiB ]

---

[ Team LiB ]