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

Route Specification
and the Hazardous Material (HazMat) code—namely the 
Cargo
.
Figure 16.9. A possible design for routing hazardous cargo
Figure 16.10.
The trouble is, this design doesn't fit the large-scale structure. The 
HazMat Route Policy
Service
is not the problem; it fits neatly into the responsibility of the Decision Support layer. The
problem is the dependency of 
Cargo
(an Operational object) on 
Router'>HazMat Route Policy Service
(a Decision Support object). As long as the project is committed to these layers, this model cannot
be allowed. It would confuse developers who expected the structure to be followed.

---

There are always many design possibilities, and we'll just have to choose another one—one that
follows the rules of the large-scale structure. The 
HazMat Route Policy Service
is all right, but
we need to move the responsibility for using the policy. Let's try giving the 
Router
the
responsibility for collecting appropriate policies before searching for a route. This means changing
the 
Router
interface to include objects that policies might depend on. Here is a possible design.
Figure 16.11. A design consistent with layering
A typical interaction is shown in Figure 16.12 on the next page.
Figure 16.12.

---

Now, this isn't necessarily a 
better
design than the other. They both have pros and cons. But if
everyone on a project makes decisions in a consistent way, the design as a whole will be much
more comprehensible, and that is worth some modest trade-offs on detailed design choices.
If the structure is forcing many awkward design choices, then in keeping with 
EVOLVING ORDER
, it
should be evaluated and perhaps modified or even discarded.