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

Paint
object held
three public integers representing red, yellow, and blue color values. The creation of the 
Pigment
Color
object did not increase the number of concepts involved or the dependencies. It did make
the ones that were already there more explicit and easier to understand. On the other hand, the
Collection
size()
operation returns an 
int
that is simply a count, the basic meaning of an
integer, so no new concept is implied.
Every dependency is suspect until proven basic to the concept behind the object. This scrutiny
starts with the factoring of the model concepts themselves. Then it requires attention to each
individual association and operation. Model and design choices can chip away at
dependencies—often to zero.
Low coupling is fundamental to object design. When you can, go all the way. Eliminate
all
other concepts from the picture. Then the class will be completely self-contained

---

and can be studied and understood alone. Every such self-contained class significantly
eases the burden of understanding a 
MODULE
.
Dependencies on other classes within the same module are less harmful than those outside.
Likewise, when two objects are naturally tightly coupled, multiple operations involving the same
pair can actually clarify the nature of the relationship. The goal is not to eliminate all
dependencies, but to eliminate all nonessential ones. If every dependency can't be eliminated,
each one that is removed frees the developer to concentrate on the remaining conceptual
dependencies.
Try to factor the most intricate computations into 
STANDALONE CLASSES
, perhaps by modeling 
VALUE
OBJECTS
held by the more connected classes.
The concept of paint is fundamentally related to the concept of color. But color, even of pigment,
can be considered without paint. By making these two concepts explicit and distilling the
relationship, the remaining one-way association says something important, and the