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

Loan
Adjustments
to the model.
Figure 8.2. A model incrementally changed to solve problems. Loan
Adjustments track departures from the share a lender originally agreed
to in the Facility.
Refinements of this kind allowed us to keep up as the rules of various transactions became clearer.
But complexity was increasing, and we did not seem to be converging quickly onto really solid
functionality.
Even more troubling were subtle rounding inconsistencies that we had not been able to squash
with increasingly complex algorithms. True, in a $100 million (MM) deal, no one cares about where
the extra pennies go, but bankers don't trust software that cannot meticulously account for those
pennies. We began to suspect that our difficulties were symptomatic of a basic design problem.

---

The Breakthrough
Suddenly one week it dawned on us what was wrong. Our model tied together the 
Facility
and
Loan
shares in a way that was 
not appropriate to the business
. This revelation had wide
repercussions. With the business experts nodding, enthusiastically helping—and, I dare say,
wondering what took us so long—we hashed out a new model on a whiteboard. Although the
details hadn't jelled yet, we knew the crucial feature of the new model: shares of the 
Loan
and
those of the 
Facility
could change independently of each other. With that insight, we walked
through numerous scenarios using a visualization of the new model that looked something like
this:
Figure 8.3. A drawdown distributed based on Facility shares
This diagram says that the borrower has chosen to draw an initial $50MM from the $100MM
committed under the 
Facility
. The three lenders chip in their shares in exact proportion to the