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

Routing
Service
and bloated its interface. The decoupling does make it clear and easily testable.
Figure 12.2. Options determined by choice of 
STRATEGY (POLICY)
 passed as
argument

---

A fundamentally important rule in the domain, the basis of choosing one 
Leg
over another when
building an 
Itinerary
, is now explicit and distinct. It conveys the knowledge that a specific
attribute (potentially derived) of an individual leg, boiled down to a single number, is the basis for
routing. This makes possible a simple statement in the language of the domain that defines the
Routing Service's 
behavior: The 
Routing Service
chooses an 
Itinerary
with a minimum total
magnitude of the 
Legs
based on the chosen 
STRATEGY
.
Note:
This discussion implies that the 
Routing Service
is actually evaluating 
Legs
as it searches
for an 
Itinerary
. This approach is conceptually straightforward, and it could make a reasonable
prototype implementation, but it is probably unacceptably inefficient. This application will be taken
up again in Chapter 14, "Maintaining Model Integrity," where the same interface will be used with a
completely different implementation of the 
Routing Service
.
When we use the technical design pattern in the domain layer, we have to add an additional
motivation, another layer of meaning. When the 
STRATEGY
corresponds to an actual business
strategy or policy, the pattern becomes more than just a useful implementation technique (though
that too is valuable as far as it goes).
The 
consequences
of the design pattern fully apply. For example, in 
Design Patterns
, Gamma et al.
point out that clients must be aware of different 
STRATEGIES
, which is also a modeling concern. A
concern purely of implementation is that 
STRATEGIES
can increase the number of objects in the
application. If that is a problem, the overhead can be reduced by implementing 
STRATEGIES
as
stateless objects that contexts can share. The extensive discussion of implementation approaches
in 
Design Patterns
all applies here. This is because we are still using a 
STRATEGY
. Our motivations
are partially different, which will affect some choices, but the experience embedded in the design
pattern is at our disposal.
[ Team LiB ]

---

[ Team LiB ]
Composite
Compose objects into tree structures to represent part-whole hierarchies. C
OMPOSITE
lets
clients treat individual objects and compositions of objects uniformly. [Gamma et al. 1995]
We often encounter, while modeling complex domains, an important object that is composed of
parts, which are themselves made up of parts, which are made up of parts—occasionally even
nesting to arbitrary depth. In some domains, each of these levels is conceptually distinct, but in
other cases, there is a sense in which the parts are the same kind of thing as the whole, only
smaller.