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

Figure 12.8. A class diagram using 
COMPOSITE

---

Now, the static class diagram does not tell us as much about how door legs and other segments fit
together as the previous one did. But the model is more than a static class diagram. We'll convey
assembly information through other diagrams (see Figure 12.9) and through the (now much
simpler) code. This model captures the deep relatedness of all these different kinds of "
Route
."
Generating the operational plan is simple again, as are other route-traversing operations.
Figure 12.9. Instances representing a complete Route

---

With a route made of other routes, pieced together end to end to get from one place to another,
you can have route implementations of varying detail. You can chop off the end of a route and
splice on a new ending, you can have arbitrary nesting of detail, and you can exploit all sorts of
possibly useful options.
Of course, we don't yet need such options. And before we needed those route segments and
distinct door legs, we were doing just fine without 
COMPOSITE
. A design pattern should be applied
only when it is needed.
[ Team LiB ]

---

[ Team LiB ]
Why Not F
LYWEIGHT?
Because I referred to the 
FLYWEIGHT
pattern earlier (in Chapter 5), you might have assumed that it
is an example of a pattern to be applied to domain models. In fact, 
FLYWEIGHT
is a good example of
a design pattern that has 
no correspondence
to the domain model.
When a limited set of 
VALUE OBJECTS
is used many times (as in the example of electrical outlets in a
house plan), it may make sense to implement them as 
FLYWEIGHTS
. This is an 
implementation
option available for 
VALUE OBJECTS
and not for 
ENTITIES
. Contrast this with 
COMPOSITE
, in which
conceptual objects are composed of other conceptual objects. In that case, the pattern applies to
both model and implementation, which is an essential trait of a domain pattern.
I'm not going to try to compile a list of the design patterns that can be used as domain patterns.
Although I can't think of an example of using an interpreter as a domain pattern, I'm not prepared
to say that there is no conception of any domain that would fit. The only requirement is that the
pattern should say something about the conceptual domain, not just be a technical solution to a
technical problem.
[ Team LiB ]

---

[ Team LiB ]