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

Example
Two C
ONTEXTS
 in a Shipping Application
We return again to the shipping system. One of the application's major features was to be the
automatic routing of cargos at booking time. The model was something like this:
Figure 14.2.

---

The 
Routing Service
is a 
SERVICE
that encapsulates a mechanism behind an 
INTENTION-REVEALING
INTERFACE
made up of 
SIDEEFFECT-FREE FUNCTIONS
. The results of those functions are characterized
with 
ASSERTIONS
.
The interface declares that when a 
Route Specification
is passed in, an 
Itinerary
will be
returned.
1.
The ASSERTION states that the returned 
Itinerary
will satisfy the 
Route Specification
that
was passed in.
2.
Nothing is stated about 
how
this very difficult task is performed. Now let's go behind the curtain to
see the mechanism.
Initially on the project on which this example is based, I was too dogmatic about the internals of
the 
Routing Service
. I wanted the actual routing operation to be done with an extended domain
model that would represent vessel voyages and directly relate them to the 
Legs
in the 
Itinerary
.
But the team working on the routing problem pointed out that, to make it perform well and to
draw on well-established algorithms, the solution needed to be implemented as an optimized
network, with each leg of a voyage represented as an element in a matrix. They insisted on a
distinct model of shipping operations for this purpose.
They were clearly right about the computational demands of the routing process as then designed,
and so, lacking any better idea, I yielded. In effect, we created two separate 
BOUNDED CONTEXTS
,
each of which had its own conceptual organization of shipping operations. (See Figure 14.3.)