0

To evaluation purpose I'm trying to set-up an event-sourcing application, its a "Personal Finance Software", the first attempt is to create an Aggregate Root (Account) who you can add entities (Transaction/s).

Account will receive lots of Transaction during software lifecycle, so every time I need to add a Transaction have to rehydrate an Aggregate more and more big.

So my fear is either:

  1. event-sourcing is not good choice in this case
  2. entities should be mapped differently.
peterbrown
  • 574
  • 6
  • 13

1 Answers1

0

This is clearly option 2).

I don't see a need why you'd need to add each transaction to an account -- where is the consistency benefit here?

Actually, in the underlying business domain, this is exactly why they (the financial guys) have introduced transactions in the first place -- a transaction is a consistent concept of an atomic financial transaction, and the account balances are usually updated a couple of hours or days after the transaction took place (cf., value date vs transaction date).

The financial domain is a perfect example where somelink like "event sourcing" and eventual consistency are frequent in the real domain as well, and they are a good fit for a long running process (saga) with eventual consistency on its aggregates.

Alexander Langer
  • 2,883
  • 16
  • 18
  • So if I understood well, I've not use the DDD style (pseudocode) Account.addTransaction(tx). Instead I shouls use (pseudocode) new Transaction(accountId, quantity...).save(). In that case how and where to check if the accountId exisits? – peterbrown Aug 21 '14 at 07:26
  • You can use `Account.credit(tx)` or similar. `new Transaction(...).save()` is not DDD-style, use a repository. How to assure that accounts exists is probably a question that you can ask your domain experts. – Alexander Langer Aug 21 '14 at 15:17