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

Example
Earning Interest the Hard Way
The next story is set in a hypothetical financial company that invests in commercial loans and
other interest-bearing assets. An application that tracks those investments and the earnings from
them has been evolving incrementally, feature by feature. Each night, one component was to run
as a batch script, calculating all interest and fees for the day and then recording them
appropriately in the company's accounting software.
Figure 9.4. An awkward model
The nightly batch script iterated through each 
Asset
, telling each to
calculateInterestForDate()
on that day's date. The script took the return value (the amount
earned) and passed this amount, along with the name of a specific ledger, to a 
SERVICE
that
provided the public interface of the accounting program. That software posted the amount to the
named ledger. The script went through a similar process to get the day's fees from each 
Asset
,
posting them to a different ledger.
A developer had been struggling with the increasing complexity of calculating interest. She started
to suspect an opportunity for a model better suited to the task. This developer asked her favorite
domain expert to help her dig into the problem area.
Developer:
Our 
Interest Calculator
is getting out of hand.

---

Expert:
That is a complicated part. We still have more cases we've been holding back.
Developer:
I know. We can add new interest types by substituting a different 
Interest
Calculator.
But what we're having the most trouble with right now is all these special cases when
they don't pay the interest on schedule.
Expert:
Those really aren't special cases. There's a lot of flexibility in when people pay.