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

Developer:
Back when we factored out the 
Interest Calculator
from the 
Asset
, it helped a lot.
We may need to break it up more.
Expert:
OK.
Developer:
I was thinking you might have a way of talking about this interest calculation.
Expert:
What do you mean?
Developer:
Well, for example, we're tracking the interest due but un-paid within an accounting
period. Do you have a name for that?
Expert:
Well, we don't really do it like that. The interest earned and the payment are quite
separate postings.
Developer:
So you don't need that number?
Expert:
Well, sometimes we might look at it, but it isn't the way we do business.
Developer:
OK, so if the payment and interest are separate, maybe we should model them that
way. How does this look? [
Sketching on whiteboard
]
Figure 9.5.
Expert:
It makes sense, I guess. But you just moved it from one place to another.
Developer:
Except now the 
Interest Calculator
only keeps track of interest earned, and the
Payment
keeps that number separately. It hasn't simplified it a lot, but does it better reflect your

---

business practice?
Expert:
Ah. I see. Could we have interest history, too? Like the 
Payment History
.
Developer:
Yes, that has been requested as a new feature. But that could have been added onto
the original design.
Expert:
Oh. Well, when I saw interest and 
Payment History
separated like that, I thought you
were breaking up the interest to organize it more like the 
Payment History
. Do you know
anything about accrual basis accounting?