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

Cargo
and 
Customer
can be traversed in only one direction, the
Cargo
REPOSITORY
will need a query that finds all 
Cargoes
for a particular 
Customer
. There were
good reasons to design it that way anyway, but with the imposition of the large-scale structure, it
is now a requirement.
Figure 16.5. A query replaces a bidirectional association that violates
the layering.
Figure 16.6. A first-pass layered model

---

While the distinction between Operations and Capability clarifies the picture, order continues to
evolve. After a few weeks of experimentation, the team zeroes in on another distinction. For the
most part, both initial layers focus on situations or plans 
as they are
. But the 
Router
(and many
other elements excluded from this example) isn't part of current operational realities or plans. It
helps make decisions about changing those plans. The team defines a new layer responsible for
"Decision Support."
"Decision Support" Responsibilities
This layer of the software provides the user with tools for planning and decision making, and it
could potentially automate some decisions (such as automatically rerouting 
Cargoes
when a
transport schedule changes).
The 
Router
is a 
SERVICE
that helps a booking agent choose the best way to send a 
Cargo
. This
places the 
Router
squarely in Decision Support.
The references within this model are all consistent with the three layers except for one discordant
element: the "is preferred" attribute on 
Transport Leg
. This attribute exists because the
company prefers to use its own ships when it can, or the ships of certain other companies with
which it has favorable contracts. The "is preferred" attribute is used to bias the 
Router
toward
these favored transports. This attribute has nothing to do with "Capability." It is a policy that
directs decision making. To use the new 
RESPONSIBILITY LAYERS
, the model will have to be
refactored.