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

Developer 1:
It sounds like 
Posting-Rule
-based firing. The batch tells each 
Posting Rule
to
execute, and the rule goes and looks for appropriate new 
Entries
and then does its thing. That's
pretty much the way you've drawn it.
Developer 2:
So then we avoid creating a lot of dependencies on the batch design, and the batch
keeps control. That sounds right.
Developer 1:
I'm still a little vague on the interaction of these objects with the 
Accounts
and
Entries
.
Developer 2:
You and me both. The examples in the book create a direct link between the
Accounts
and the 
Posting Rules
. That is kind of logical, but I don't think it will work very well for
us. We have to instantiate these objects from data each time, so we would have to figure out
which rule applies in order to associate it. Meanwhile, the 
Asset
object is the one that knows the
content of each 
Account
, and therefore which rule to apply. Anyway, what about the rest of this?
Developer 1:
I hate to nitpick, but I don't think that we're using "
Method
" right. I think the
concept is that the 
Method
computes the amount to be posted—like, say, a 20 percent tax with-
holding on income. But in our case, that's simple: it's always the full amount being posted. I think
the 
Posting Rule
itself is supposed to know which 
Account
to post to, which corresponds to our
"ledger name."
Developer 2:
Oh. So if the 
Posting Rule
is responsible for knowing the correct ledger name, we
probably don't need 
Method
at all.
Actually, this whole business of choosing the right ledger name is getting more and more
complicated. It is already a combination of the type of income (fee or interest) with the "asset
class" (a category the business applies to each