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

A Decent Model, and Yet . . .
We were feeling pretty good. Four months before, we had been in deep trouble with a completely
unworkable, inherited code base, which we had since wrestled into a coherent 
MODEL-DRIVEN
DESIGN
.
The model reflected in Figure 8.1 makes the common case very simple. The 
Loan Investment
is
a derived object that represents a particular investor's contribution to the 
Loan,
proportional to its
share in the 
Facility
.
Figure 8.1. A model that assumes lender shares are fixed

---

What Is a "Facility"?
A "facility" in this context is not a building. As on most projects, specialized terminology
from the domain experts entered our vocabulary and became part of the 
UBIQUITOUS
LANGUAGE
. In the domain of commercial banking, 
a facility is a commitment by a
company to lend
. Your credit card is a facility that entitles you to borrow on demand up
to a prearranged limit at a predetermined interest rate. When you use the card, you
create an outstanding loan, and each additional charge is a 
drawdown
against your
facility that increases the loan. Finally you pay back the loan principal. You may also
pay an annual fee. This is a fee for the privilege of having the card (the facility) and is
independent of your loan.
But there were some disconcerting signs. We kept stumbling over unexpected requirements that
complicated the design. A major example was the creeping understanding that the shares in a
Facility 
were only a 
guideline
to participation in any particular loan draw-down. When the
borrower requests its money, the leader of the syndicate calls all members for their shares.
When called, the investors usually cough up their share, but often they negotiate with other
members of the syndicate and invest less (or more). We had accommodated this by adding