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

Expert:
So we're not going to have the 
Account
object? I was looking forward to being able to
see everything together there, with the accruals and the payments and a balance.
Developer 1:
Really?! Well in that case, maybe 
this
would work. [
Takes other diagram and
sketches
]
Figure 11.6. The account-based diagram, without Transaction
Expert:
That actually looks pretty good!
Developer 2:
The batch script will be easy to change to use these new objects.
Developer 1:
It will take a few days to get the new 
Interest Calculator
working. There are
quite a few tests to change. But the test will read clearer afterward.
The two developers went off and started refactoring based on the new model. As they got their
hands on the code, tightening up the design, they had insights that refined the model.
Entries_were_subclassed_into_Payment_and_Accrual'>Entries
were subclassed into 
Payment
and 
Accrual
because closer inspection revealed slightly
different responsibilities in the application for these, and because they were both important domain
concepts. On the other hand, there was no conceptual or behavioral distinction between 
Entries
based on whether they resulted from fees or interest. They simply appeared in the appropriate
Account
.
Yet, unfortunately, the developers found they had to give up this last abstraction for the

---

implementation. Data was stored in relational tables, and the project standard was to make those
tables interpretable without running the program. This meant keeping fee entries and interest
entries in separate tables. The only way for developers to do this, using their particular object-
relational mapping framework, was to make concrete subclasses (