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

Account
to another.
Figure 11.3. A transaction model
This is the well-established concept of 
double-entry book-keeping
: Every credit has a
matching debit. Of course, like other conservation principles, it applies only to a closed
system, one that includes all sources and sinks. Many simple applications do not require this
rigor.
In his book, Fowler includes more elaborate forms of these models and considerable
discussion of the trade-offs.
This reading gives the developer (
Developer 1
) several new ideas. She shows the chapter to a
colleague (
Developer 2
) who has been working on some of the interest calculation logic with her
and who wrote the nightly batch program. Together, they rough out a change to their model,
incorporating some of the model elements they've read about.
Figure 11.4. The new model proposal

---

Then they pull in their domain expert (
Expert
) for a discussion of their new model ideas.
Developer 1:
With this new model, we make an 
Entry
into the 
Interest Account
for the interest
earned, rather than just adjusting the interestDueAmount. Then, another 
Entry
for the payment
balances it out.
Expert:
So now we'd be able to see a history of all the interest accruals as well as the payment
history? That's something we've been wanting.
Developer 2:
I'm not sure we've used "
Transaction
" quite right. The definition talks about
moving money from one 
Account
to another, not two entries that balance each other in the same
Account
.
Developer 1:
That's a good point. I was also worried that the book seems to make quite a point
about the transaction being created all at once. The interest payments can be several days late.