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

Making an Implicit Concept Explicit
There are enough pointers now to start probing for that new model. The 
Share
objects are passive
in this implementation, and they are being manipulated in complex, low-level ways. This is
because most of the rules and calculations about shares don't apply to single shares, but to groups
of them. There is a missing concept: shares are related to each other as parts making up a whole.
Making this concept explicit will let us express those rules and calculations more succinctly.
Figure 10.18.
The 
Share Pie
represents the total distribution of a specific 
Loan
. It is an 
ENTITY
whose identity is
local within the 
AGGREGATE
of the 
Loan
. The actual distribution calculations can be delegated to
the 
Share Pie
.

---

Figure 10.19.
public class Loan {
private SharePie shares;
//Accessors, constructors, and straightforward methods
//are omitted
public Map calculatePrincipalPaymentDistribution(
double paymentAmount) {
return getShares().prorated(paymentAmount);
}
public void applyPrincipalPayment(Map paymentShares) {
shares.decrease(paymentShares);
}
}
The 
Loan
is simplified, and the 
Share
calculations are centralized in a 
VALUE OBJECT
focused on
that responsibility. Still, the calculations haven't really become more versatile or easier to use.
Share Pie Becomes a V
ALUE
 O
BJECT
: Cascade of Insights
Often, the hands-on experience of implementing a new design will trigger a new insight into the
model itself. In this case, the tight coupling of the 
Loan
and