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

The Suppleness of the New Design
At this point, the methods in the all-important 
Loan
class could be as simple as this:
public class Loan {
private SharePie shares;
//Accessors, constructors, and straightforward methods
//are omitted
public SharePie calculatePrincipalPaymentDistribution(
double paymentAmount) {
return shares.prorated(paymentAmount);
}
public void applyPrincipalPayment(SharePie paymentShares) {
setShares(shares.minus(paymentShares));
}
Each of these short methods states its 
meaning
. Applying a principal payment means that you
subtract the payment from the loan, share by share. Distributing a principal payment is done by
dividing the amount 
pro rata
among the shareholders. The design of the 
Share Pie
has allowed us
to use a declarative style in the 
Loan
code, producing code that begins to read like a conceptual
definition of the business transaction, rather than a calculation.
Other transaction types (too complicated to list before) can be declared easily now. For example,
loan drawdowns are divided among lenders based on their shares of the 
Facility
. The new draw-
down is added to the outstanding 
Loan
. In our new domain language:

---

public class Facility {
private SharePie shares;
. . .
public SharePie calculateDrawdownDefaultDistribution(
double drawdownAmount) {
return shares.prorated(drawdownAmount);
}
}
public class Loan {
. . .
public void applyDrawdown(SharePie drawdownShares) {
setShares(shares.plus(drawdownShares));
}
}
To see the deviation of each lender from its agreed contribution, take the theoretical distribution of
the outstanding