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

Figure 5.1. Some traversal directions reflect a natural bias in the
domain.

---

Very often, deeper understanding leads to a "qualified" relationship. Looking deeper into
presidents, we realize that (except in a civil war, perhaps) a country has only one president at a
time. This qualifier reduces the multiplicity to one-to-one, and explicitly embeds an important rule
into the model. Who was president of the United States in 1790? George Washington.
Figure 5.2. Constrained associations communicate more knowledge
and are more practical designs.
Constraining the traversal direction of a many-to-many association effectively reduces its
implementation to one-to-many—a 
much 
easier design.
Consistently constraining associations in ways that reflect the bias of the domain not only makes
those associations more communicative and simpler to implement, it also gives significance to the
remaining bidirectional associations. When the bidirectionality of a relationship is a semantic
characteristic of the domain, when it's needed for application functionality, the retention of both
traversal directions conveys that.
Of course, the ultimate simplification is to eliminate an association altogether, if it is not essential
to the job at hand or the fundamental meaning of the model objects.
Example
Associations in a Brokerage Account

---

Figure 5.3.
One Java implementation of 
Brokerage Account
in this model would be
public class BrokerageAccount {
String accountNumber;
Customer customer;
Set investments;
// Constructors, etc. omitted
public Customer getCustomer() {
return customer;
}
public Set getInvestments() {
return investments;
}
}
But if we need to fetch the data from a relational database, another implementation, equally
consistent with the model, would be the following: