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

Example
Earning Interest by the Book
Let's imagine a different scenario for the investment-tracking application discussed in the previous
example. Just as before, the story starts with the developer realizing that the design is getting
unwieldy, particularly the 
Interest Calculator
. But in this scenario, the domain expert's primary
responsibilities lie elsewhere, and he doesn't have much interest in helping the software
development project. In this scenario, the developer couldn't turn to the expert for a
brainstorming session to probe for the missing concepts she suspected to be lurking under the
surface.
Instead, she went to the bookstore. After a little browsing, she found an introductory accounting
book she liked, and she skimmed it. She discovered a whole system of well-defined concepts. An
excerpt that particularly fired her thinking:
Accrual Basis Accounting
. This method recognizes income when it is earned, even if it is
not paid. 
All
expenses also show when they are incurred whether they have been paid for or
billed to be paid at a later date. Any obligation due, including taxes, will be shown as
expense.
—
Finance and Accounting: How to Keep Your Books and Manage Your Finances Without an
MBA, a CPA or a Ph.D.,
by Suzanne Caplan (Adams Media, 2000)
The developer no longer needed to reinvent accounting. After some brainstorming with another
developer, she came up with a model.
Figure 9.9. A somewhat deeper model based on book learning
She did not have the insight that 
Assets
are income generators, and so the 
Calculators
are still
there. The knowledge of ledgers is still in the application, rather than the domain layer where it
probably belongs. But she did separate the issue of payment from the accrual of income, which

---

was the most problematic area, and she introduced the word "accrual" into the model and into the
UBIQUITOUS LANGUAGE
. Further refinement could come with later iterations.
When she did finally have the chance to talk with the domain expert, he was quite surprised. It
was the first time a programmer had shown a glimmer of interest in what he did. Due to the way
his responsibilities were assigned, the expert never engaged with her, sitting down to go over the
model, as happened in the previous scenario. However, because this developer's knowledge
allowed her to ask better questions, from then on the expert did listen to her carefully, and he
made a special effort to answer her questions promptly.
Of course, this is not an either-or proposition. Even with ample support from domain experts, it
pays to look at the literature to get a grasp of the theory of the field. Most businesses do not have
models refined to the level of accounting or finance, but in many there have been thinkers in the
field who have organized and abstracted the common practices of the business.
Yet another option the developer had was to read something written by another software
professional with development experience in this domain. For example, Chapter 6 of the book
Analysis Patterns: Reusable Object Models
(Fowler 1997) would have sent her in quite a different
direction, not necessarily better or worse. Such reading would not have provided an off-the-shelf
solution. It would have given several new starting points for her own experiments, along with the
distilled experience of people who have traveled the territory. She would have been spared
reinventing the wheel. Chapter 11, "Applying Analysis Patterns," will delve further into this option.