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

Developer:
Please explain.
Expert:
Each day, or whenever the schedule calls for, we have an interest accrual that gets
posted to a ledger. The payments are posted a different way. This aggregate you have here is a
little awkward.
Developer:
You're saying that if we keep a list of "accruals," they could be aggregated or . . .
"posted" as needed.
Expert:
Probably posted on the accrual date, but yes, aggregated any-time. Fees work the same
way, posted to a different ledger, of course.
Developer:
Actually, the interest calculation would be simpler if it was done just for one day, or
period. And then we could just hang on to them all. How about this?
Figure 9.6.
Expert:
Sure. It looks good. I'm not sure why this would be easier for you. But basically, what
makes any asset valuable is what it can accrue in interest, fees, and so on.
Developer:
You said fees work the same way? They . . . what was it . . . post to different ledgers?

---

Figure 9.7.
Developer:
With this model, we get the interest calculation, or rather, the accrual calculation logic
that was in the 
Interest Calculator 
separated from tracking. And I hadn't noticed until now how
much duplication there is in the 
Fee Calculator
. Also, now the different kinds of fees can easily be
added.
Expert:
Yes, the calculation was correct before, but I can see everything now.
Because the 
Calculator
classes hadn't been directly coupled with other parts of the design, this
was a fairly easy refactoring. The developer was able to rewrite the unit tests to use the new
language in a few hours and had the new design working late the next day. She ended up with
this.