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

3.
Developer 2
needed a sounding board to discuss his new ideas. He met up his colleague
(
Developer 1
), the developer who had been primarily responsible for modeling the accruals.
Developer 2:
At some point, the nightly batch started being a place where we swept stuff under
the rug. There is domain logic implicit in what the script does, and it's been getting more and more
complicated. For a long time I've wanted to do a model-driven design for the batch, separate out a
domain layer, and make the script itself a simple layer on top of the domain. But I could never
figure out what that domain model would be like. It seemed like maybe it was just some
procedures that didn't really make sense as objects. As I've been reading the section in 
Analysis
Patterns
on 
Posting Rules
, I've been getting some ideas. Here's what I had in mind. [
Hands over
a sketch
]
Figure 11.9. A shot at using Posting Rules in the batch
Developer 1:
What is this "
Posting Service
"?
Developer 2:
That is a 
FACADE
that exposes the accounting application's API and presents it as a
SERVICE
. I actually made that a while back to simplify the batch code, and it also gave me an
INTENTION-REVEALING INTERFACE
for posting to the legacy system.
Developer 1:
Interesting. So, which firing style do you plan to use for these 
Posting Rules
?
Developer 2:
I hadn't really gotten that far.
Developer 1:
Eager Firing would work for 
Accruals
, since the batch actually tells the 
Asset
to
insert them, but it wouldn't work for 
Payments
, which get entered during the day.

---

Developer 2:
I don't think we would want to couple the calculation method that tightly to the
batch anyway. If we ever decided to trigger interest calculations at a different time, it would mess
things up. And it just doesn't seem right, conceptually.