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

Example
Route-Finding Policies
A 
Route Specification
is being passed to a 
Routing Service
, whose job is to construct a
detailed 
Itinerary
that satisfies the 
SPECIFICATION
. This 
SERVICE
is an optimization engine that can
be tuned to find either the fastest route or the cheapest one.
Figure 12.1. A 
SERVICE
 interface with options will need conditional logic.
This setup looks OK, but a detailed look at the routing code would reveal conditionals in every
computation, making the decision between fastest or cheapest appear all over the place. More
trouble will come when new criteria are added to make more subtle choices between routes.
One approach is to separate those tuning parameters into 
STRATEGIES
. Then they can be
represented explicitly, passed into the 
Routing Service
as a parameter.
The 
Routing Service
now handles all requests in the same, unconditional way, looking for a
sequence of 
Legs
with a low magnitude, as computed by the 
Leg Magnitude Policy
.
This design has the advantages that motivate the 
STRATEGY
pattern in 
Design Patterns
. On the
level of application versatility and flexibility, the behavior of the 
Routing Service
can now be
controlled and extended by installing an appropriate 
Leg Magnitude Policy
. The 
STRATEGIES
illustrated in Figure 12.2 (fastest or cheapest) are only the most obvious ones. Combinations that
balance speed and cost are likely. There may be other factors altogether, such as a bias toward
booking cargo on the company's own transports rather than subcontracting to carry them on the
transports of other shipping companies. These modifications could have been made without
resorting to 
STRATEGIES
, but the logic would have wound through the internals of the