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

Standalone Classes
Interdependencies make models and designs hard to understand. They also make them hard to
test and maintain. And interdependencies pile up easily.
Every association is, of course, a dependency, and understanding a class requires understanding
what it is attached to. Those attached things will be attached to still more things, and they have to
be understood too. The type of every argument of every method is also a dependency. So is every
return value.
With one dependency, you have to think about two classes at the same time, and the nature of
their relationship. With two dependencies, you have to think about each of the three classes, the
nature of the class's relationship to each of them, and any relationship they might have to each
other. If they in turn have dependencies, you have to be wary of those also. With three
dependencies . . . it snowballs.
Both 
MODULES
and 
AGGREGATES
are aimed at limiting the web of interdependencies. When a highly
cohesive subdomain is carved out into a 
MODULE
, a set of objects are decoupled from the rest of
the system, so there are a finite number of interrelated concepts. But even a 
MODULE
can be a lot
to think about without an almost fanatical commitment to controlling dependencies within it.
Even within a 
MODULE
, the difficulty of interpreting a design increases wildly as
dependencies are added. This adds to mental overload, limiting the design complexity a
developer can handle. Implicit concepts contribute to this load even more than explicit
references.
Refined models are distilled until every remaining connection between concepts represents
something fundamental to the meaning of those concepts. In an important subset, the number of
dependencies can be reduced to zero, resulting in a class that can be fully understood all by itself,
along with a few primitives and basic library concepts.
In every programming environment, a few basics are so pervasive that they are always in mind.
For example, in Java development, primitives and a few standard libraries provide basics like
numbers, strings, and collections. Practically speaking, "integers" don't add to the intellectual load.
Beyond that, every additional concept that has to be held in mind in order to understand an object
contributes to mental overload.
Implicit concepts, recognized or unrecognized, count just as much as explicit references. Although
we can generally ignore dependencies on primitive values such as integers and strings, we can't
ignore 
what they represent
. For example, in the first paint mixing examples, the