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

Expert:
Those payments aren't necessarily late. There is a lot of flexibility in when they pay.
Developer 1:
So this may be a blind alley. I was thinking we might have identified some implicit
concepts. Having the 
Interest Calculator
create 
Entry
objects does seem to communicate
better. And 
Transaction
seemed to neatly tie together the calculated interest with the payment.
Expert:
Why do we need to tie together the accrual to the payment? They are separate postings
in the accounting system. The balance on the 
Account
is the main thing. Along with the individual
Entries,
we really have what we need.
Developer 2:
You mean you don't track whether they've made the interest payment?
Expert:
Well, of course we do. But it isn't as simple as this one-accrual/one-payment scheme of
yours.
Developer 2:
It could actually simplify a lot of things to stop worrying about that connection.
Developer 1:
OK, how about this? [
Takes copy of old class diagram and starts sketching
modifications
] By the way, you used the word 
accruals
a few times. Could you clarify what it
means?
Expert:
Sure. An accrual is just when you account for an expense or income at the time it is
incurred, never mind when money actually changes hands. So, we accrue interest every day, but
at the end of the month (for example) we receive a payment against it.
Developer 1:
Yes, we really needed a word like that. OK, how does this look?

---

Figure 11.5. Original class diagram, accruals separated from payment
Developer 1:
Now we can get rid of all the complications that were in the calculator from relating
payments, and we've introduced the term 
accruals
, which reveals the intent better.