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

Figure 8.7. An abstract model of shares
I also sketched a new loan model to go with it.
Figure 8.8. The Loan model using Share Pie
There were no longer specialized objects for the shares of a 
Facility
or a 
Loan
. They both were
broken down into the more intuitive "
Share Pie.
" This generalization allowed the introduction of
"shares math," vastly simplifying the calculation of shares in any transaction, and making those
calculations more expressive, concise, and easily combined.
But most of all, problems went away because the new model removed an inappropriate constraint.
It freed the 
Loan's Shares
to depart from the proportions of the 
Facility's Shares
, while
keeping in place the valid constraints on totals, fee distributions, and so on. The 
Share Pie
of the
Loan
could be adjusted directly, so the 
Loan Adjustment
was no longer needed, and a large
amount of special-case logic was eliminated.
The 
Loan Investment
had disappeared, and at this point we realized that "loan investment" was
not a banking term. In fact, the business experts had told us a number of times that they didn't
understand it. They had deferred to our software knowledge and assumed it was useful to the
technical design. Actually, we had created it based on our incomplete understanding of the
domain.

---

Suddenly, on the basis of this new way of looking at the domain, we could run through every
scenario we had ever encountered relatively effortlessly, much more simply than ever before. 
And
our model diagrams made perfect sense to the business experts, who had often indicated that the
diagrams were "too technical" for them.
Even just sketching on a whiteboard, we could see that
our most persistent rounding problems would be pulled out by the roots, allowing us to scrap some
of the complicated rounding code.
Our new model worked well. Really, really well.
And we all felt sick!