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

When the relatedness of nested containers is not reflected in the model, common
behavior has to be duplicated at each level of the hierarchy, and nesting is rigid (for
example, containers can't usually contain other containers at their own level, and the
number of levels is fixed). Clients must deal with different levels of the hierarchy
through different interfaces, even though there may be no conceptual difference they
care about. Recursion through the hierarchy to produce aggregated information is very
complicated.
When applying any design pattern in the domain, the first concern should be whether the pattern
idea really is a good fit for the domain concept. It might be convenient to move recursively
through some associated objects, but is there a true whole-part hierarchy? Have you found an
abstraction under which all the parts truly are the same conceptual type? If you have, 
COMPOSITE
will make those aspects of the model clearer, while allowing you to tap into the carefully thought-
out design and implementation considerations of the design pattern.
Therefore:
Define an abstract type that encompasses all members of the 
COMPOSITE
. Methods that
return information are implemented on containers to return aggregated information
about their contents. "Leaf" nodes implement those methods based on their own
values. Clients deal with the abstract type and have no need to distinguish leaves from
containers.
This is a relatively obvious pattern on the structural level, but designers often do not push

---

themselves to flesh out the operational level of the pattern. The 
COMPOSITE
offers the same
behavior at every structural level, and meaningful questions can be asked of small or large parts
that transparently reflect their makeup. That rigorous symmetry is the key to the power of the
pattern.