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

Asset
). That is one place I'm hoping this new
model will help.
Developer 1:
OK, let's focus there. The 
Posting Rule
is responsible for choosing the Ledger
based on attributes of the 
Account
. For now, we can make it a straightforward way to handle
asset class and the distinction between interest and fees. In the future, you'll have an 
OBJECT
MODEL
you can enhance to handle more complex cases.
Developer 2:
I need to think about this some more. Let me mull it over, and reread the patterns,
and then I'll take another stab at it. Could I talk with you about this again tomorrow afternoon?
Over the next few days, the two developers worked out a model and refactored the code so that
the batch simply iterated through the 
Assets
, sending a few self-explanatory messages to each
and then committing the database transactions. The complexity was shifted into the domain layer,
where an object model made it both more explicit and more abstract.
Figure 11.10. The class diagram with Posting Rules

---

Figure 11.11. Sequence diagram showing rule firing
The developers departed considerably from the details of the models presented in 
Analysis
Patterns,
yet they felt they had preserved the essence of the concepts. They were a little
uncomfortable about involving the 
Asset
in the selection of the 
Posting Rule
. They went that
way because the 
Asset
had the knowledge of the nature of each 
Account
(fee or interest) and
was also the natural access point for the script. To have associated the rule object directly with the
Account
would have required a collaboration with the