2

How can I go about designing a double entry accounting system using event sourcing? I read that this is a domain where event sourcing is applicable and it seems intuitive to me, storing all the events that affects the ledger and having the ledger built in memory from these events. Any pointers on how to architect such a system?

Svetlin Zarev
  • 14,713
  • 4
  • 53
  • 82
skrill0
  • 29
  • 2
  • Hi, is your primary interest in double entry accounting, event sourcing, or using an in-memory approach? Just want to make sure I understand so I (we?) can focus on what you want. Also, how familiar are you with event sourcing? – Adrian K Jul 24 '21 at 06:06
  • I would advise looking into domain driven design (esp. around the idea of decomposition into aggregates). – Levi Ramsey Jul 24 '21 at 12:20
  • My intention is to build an accounting system, I was going to go about it the traditional way by having a ledger table, the approach which is clear to me. I was trying to find alternatives to the traditional relational approach and try an in-memory solution on the side as the data in the ledger tables would be queried heavily for analytics. The thought was to have an event-sourced system where all the transactions that would create an entry in the ledger could be considered as events, now I can recreate the ledger in memory when the application starts up. I'm new to the concept of event sourci – skrill0 Jul 24 '21 at 16:28
  • In event sourcing an event stream of some entity should be an ultimate source of truth. The question is, what is this entity. An account? But there are multiple involved in a transaction. Then what comes to my mind is a bank branch's transaction list, whatever it is called. This matches the definition of transaction and composes a strict sequence. – iTollu Jul 24 '21 at 18:52
  • Transaction as an event is what I was picturing. I make a withdrawal of some sort, changes to all the accounts affected by it will be tied up as a transaction and bottled up as an event. – skrill0 Jul 25 '21 at 08:12

1 Answers1

0

In event sourcing the ultimate source of truth about an entity in a given point in time is its strictly ordered sequence of events.

The crucial part of event sourcing is the decision making whether to persist another event or not. Usually you need the current state to make up such decision. The entity should not change between retrieval of the current state and persisting another event. It means, you lock on it.

Look for an inspiration at the physical pre-computer event-sourced systems. Metric books, banking systems, medical records. In these cases some physical book is a token that does the lock: no two people can write to such book simultaneously.

Thinking about designing an event-sourced system, you should ask yourself: what could be an entity in your system? What to lock on? What event sequence could make sense?

For an event-sourced banking system one option is a strict sequence of all account transactions in a given bank branch. From this sequence of events you can derive (calculate) the state of any account.

As in a physical system, you can start a fresh sequence each financial quarter. Most likely you will store transactions of individual accounts separately, in a derived model. You could also store separately the current balance of each account. All these derived models would be eventually consistent with the ultimate sequence of transactions. If you need exactly the current state - you then can update the derived model with the latest events...

So, you get the idea. There are many lessons to learn from the physical event-sourced systems. Just dig deeper into the domain.

But what about double-entry? Here you are: in each transaction (event) the amount is accounted twice. On the debit side and on the credit side of the transaction.

iTollu
  • 999
  • 13
  • 20