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

Figure 14.3. Two 
BOUNDED CONTEXTS
 formed to allow efficient routing
algorithms to be applied

---

Our requirement was to take a 
Routing Service
request, translate it into terms the 
Network
Traversal Service
could understand, then take the result and translate it into the form a
Routing Service
is expected to give.
This means it was not necessary to map everything in these two models, but only to be able to
make two specific translations:
Route Specification
List
of location codes
List of 
Node
IDs 
Itinerary
To do this, we have to look at the meaning of an element of one model and figure out how to
express it in terms of the other.
Starting with the first translation (
Route Specification
List
of location codes), we have to
think about the meaning of the sequence of locations in the list. The first in the list will be the
beginning of the path, which will then be forced to pass through each location in turn until it
reaches the last location in the list. So the origin and destination are the first and last in the list,
with the customs clearance location (if there is one) in the middle.
Figure 14.4. Translation of a query to the Network Traversal Service

---

(Mercifully, the two teams used the same location codes, so we don't have to deal with that level
of translation.)
Notice that the reverse translation would be ambiguous, because the network traversal input
allows any number of intermediate points, not just one specifically designated as customs
clearance point. Fortunately, this is no problem because we don't need to translate in that
direction, but it gives a glimpse of why some translations are impossible.
Now, let's translate the result (