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

Fee Payments, Interest
Payments
, and so on). With different infrastructure, they might have avoided this clumsy
expansion.
I threw this twist into this largely fictitious story to represent the rub of reality that we encounter
all the time. We have to make calculated compromises and then move on without letting it throw
us off our 
MODEL-DRIVEN DESIGN
.
Figure 11.7. The class diagram after the implementation
The new design was much easier to analyze and test because the most complex functionality is in
SIDE-EFFECT-FREE FUNCTIONS
. The remaining command has simple code (because it calls various
FUNCTIONS
) and is characterized by 
ASSERTIONS
.
Sometimes there are parts of our programs that we don't even suspect have the potential to
benefit from a domain model. They may have started very simply and evolved mechanistically.
They seem like complicated application code, rather than domain logic. Analysis patterns can be
particularly helpful in showing us these blind spots.
In the following example, a developer has a new insight into the black box of the nightly batch,
which had not been considered domain oriented.
[ Team LiB ]

---

[ Team LiB ]
Example
Insight into the Nightly Batch
After a few weeks, the improved 
Account
-based model had started to settle in. As often happens,
the clarity of the new design made other problems more visible. The developer (
Developer 2
)
who was adapting the nightly batch to interact with the new design began to see connections
between the behavior of the batch and some of the concepts in 
Analysis Patterns
. Here is a
summary of some of the concepts he found most relevant.
Posting Rules
Accounting systems often provide multiple views of the same basic financial information. One
account might track income while another might track an estimated tax on that income. If
the system is expected to automatically update the estimated tax account, the
implementation of those two accounts becomes very intertwined. There are systems in which
the majority of account entries result from such rules; in such a system, the dependency
logic gets to be a mess. Even in more modest systems, such cross-posting can be tricky. The
first step toward taming the tangle of dependencies is to make these rules explicit by
introducing a new object.