Dear @alexey.zimarev, @chris.condron,
i find the discussion and the topic of event sourcing in connection with bank accounts very exciting and have often thought about it.
I had already started a thread on this in the EM Slack Channel. (https://eventmodeling.slack.com/archives/CKLVCU941/p1624969217169800)
What I miss in the discussion here in this thread, however, is the double-entry bookkeeping approach.
So far you are only talking about ONE account. In theory, however, a transaction is always posted to at least 2 accounts (two-legged transaction, multi-legged transaction - see also M. Fowler’s accounting pattern) and the total of a transaction always results in a zero balance.
So even if you look at an account to which something is credited (single remittance), there is always a counter account within the bank from which the money is debited (nostro & vostro accounts).
If you now take both bank accounts as an aggregate, how do you ensure transaction security so that both bookings are surely written in both streams? That is not really possible. As I understand it, the only source of truth in double entry bookkeeping is the journal. Based on a transaction, this results in a journal entry which, if this has been successfully added to the journal, generates the resulting account entries. These account entries are then posted to the respective (general) ledger accounts, which could actually exist as pure reading models.
I think it is important to differentiate between bank accounts and accounting accounts because they actually live in different domains (bank account -> payments domain, accounting accounts -> accounting domain)
So what is the actual status of a bank account in payments and what is it in the ledger account (or sub-ledger account) in accounting?
I believe for the accounting account it is all account entries in a limited period, as you mentioned already. But in this case I would not see the account as an aggregate, but rather the journal or the main and sub-ledgers.
For the payment account, there are more technical things, such as account holder, credit line, reporting period, authorizations, etc. All other account-relevant things, such as the current balance, available balance, account transactions or account statements, could exist as pure read models.
So accounting always seems to be the best example to describe event sourcing from scratch, but thinking about implementing it raises questions for me again and again.
Would appreciate hearing your thoughts on this.