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

Associations
The interaction between modeling and implementation is particularly tricky with the associations
between objects.
For every traversable association in the model, there is a mechanism in the software with the
same properties.
A model that shows an association between a customer and a sales representative corresponds to
two things. On one hand, it abstracts a relationship developers deemed relevant between two real
people. On the other hand, it corresponds to an object pointer between two Java objects, or an
encapsulation of a database lookup, or some comparable implementation.
For example, a one-to-many association might be implemented as a collection in an instance
variable. But the design is not necessarily so direct. There may be no collection; an accessor
method may query a database to find the appropriate records and instantiate objects based on
them. Both of these designs would reflect the same model. The design has to specify a particular
traversal mechanism whose behavior is consistent with the association in the model.
In real life, there are lots of many-to-many associations, and a great number are naturally
bidirectional. The same tends to be true of early forms of a model as we brainstorm and explore
the domain. But these general associations complicate implementation and maintenance.
Furthermore, they communicate very little about the nature of the relationship.
There are at least three ways of making associations more tractable.
Imposing a traversal direction
1.
Adding a qualifier, effectively reducing multiplicity
2.
Eliminating nonessential associations
3.
It is important to constrain relationships as much as possible. A bidirectional association means
that both objects can be understood only together. When application requirements do not call for
traversal in both directions, adding a traversal direction reduces interdependence and simplifies
the design. Understanding the domain may reveal a natural directional bias.
The United States has had many presidents, as have many other countries. This is a bidirectional,
one-to-many relationship. Yet we seldom would start out with the name "George Washington" and
ask, "Of which country was he president?" Pragmatically, we can reduce the relationship to a
unidirectional association, traversable from country to president. This refinement actually reflects
insight into the domain, as well as making a more practical design. It captures the understanding
that one direction of the association is much more meaningful and important than the other. It
keeps the "Person" class independent of the far less fundamental concept of "President."