CQRS, DDDD in an accounting domain

Question

I'm wondering how to properly model my aggregates. The domain is accounting and I have three entities: Account, AccountingEntry (should this be a value object instead?) and AccountingTransaction. The account could be say, a customer's bank account. The AccountingEntry is an entry in the account and AccountingTransaction ties several entries that constitute a single transaction (e.g. transfer from account A to account B). together.

My thinking is to model Account and AccountingTransaction as aggregates and AccountingEntry as a collection within AccountingTransaction. This is to allow the accounting transaction aggregate enforce the invariant that says all entries in a transaction must sum to zero. The entries will hold a reference to the ID of their associated accounts (this will be useful if say, we want to reverse the transaction). The accounts would not hold any references to the entries but will hold a balance.

I would use a saga to manage the process of crediting and debiting accounts transactionally.

I would like to know if I'm modeling this right.

I would also like to know how to ensure an accounting entry cannot be created that would hold a reference (ID) to an invalid (non existent) account. Should the account be used as the factory for creating the entry, passing in it's own ID?

Answer 1

I think the model is pretty nice. You could use Transaction as the Entry's factory(use Account as arguments) according to Martin Fowler's Accoutning Pattern.