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

List
of 
Node
IDs 
Itinerary
). We'll assume that we can use a
REPOSITORY to look up the 
Node
and 
Shipping Operation
objects based on the 
Node
IDs we
receive. So, how do those 
Nodes
map to 
Legs
? Based on the 
operationType-Code
, we can break
the list of 
Nodes
into departure/arrival pairs. Each pair then relates to one 
Leg
.
Figure 14.5. Translation of a route found by the Network Traversal
Service
The attributes for each 
Node
pair would be mapped as follows:
departureNode.shippingOperation.vesselVoyageId 
leg.vesselVoyageId
departureNode.shippingOperation.date 
leg.loadDate
departureNode.locationCode 
leg.loadLocationCode
arrivalNode.shippingOperation.date 
leg.unloadDate
arrivalNode.locationCode 
leg.unloadLocationCode

---

This is the conceptual translation map between these two models. Now we have to implement
something that can do the translation for us. In a simple case like this, I typically create an object
for the purpose, and then find or create another object to provide the service to the rest of our
subsystem.
Figure 14.6. A two-way translator
This is the one object that both teams have to work together to maintain.
The design should make
it very easy to unit-test, and it would be a particularly good idea for the teams to collaborate on a
test suite for it. Other than that, they can go their separate ways.
Figure 14.7.
The 
Routing Service
implementation now becomes a matter of delegating to the Translator and
the Network Traversal Service. Its single operation would look something like this:
public Itinerary route(RouteSpecification spec) {
Booking_TransportNetwork_Translator translator =
new Booking_TransportNetwork_Translator();]
List constraintLocations =
translator.convertConstraints(spec);

---

// Get access to the NetworkTraversalService
List pathNodes =
traversalService.findPath(constraintLocations);
Itinerary result = translator.convert(pathNodes);
return result;
}
Not bad. The 
BOUNDED CONTEXTS
served to keep each of the models relatively clean, let the teams
work largely independently, and if initial assumptions had been correct, would probably have
served well. (We'll return to that later in this chapter.)
The interface between the two contexts is fairly small. The interface of the 
Routing Service
insulates the rest of the Booking 
CONTEXT
's design from events in the route-finding world. The
interface is easy to test because it is made up of 
SIDE-EFFECT-FREE FUNCTIONS
. One of the secrets to
comfortable coexistence with other 
CONTEXTS
is to have effective sets of tests for the interfaces.
"Trust, but verify," said President Reagan when negotiating arms reductions.
[1]
[1]
Reagan translated an old Russian saying that summed up the heart of the matter for both sides—another
metaphor for bridging contexts.
It should be easy to devise a set of automated tests that would feed