Good practices for modelling double-entry Accounting domain with Actors?

Akka Actors
1

Hi Akka fans!

I’m a newbie to Akka and try to understand how I could model a software to handle simple transactions for a double-entry accounting system.

My first thoughts:

  • Model transactions as Actors themselves, so I would have “Transaction Actors” to handle incoming transactions with credit/debit values, etc.
  • Model each account as Actor and sending transaction events to these account Actors
  • Using somehow both of the modelling approaches above, because I need the handling of transactions but also somehow having the state of every account to calculate then the credit/debit difference and to be able to create reports

What would you recommend or what approaches are common in the context of the Actor model? Or would you say that using Actors for this type of software is not really a good match?

Thanks for sharing your thoughts about this topic!

2

The transfer saga that Roland describes in this lecture might be interesting to watch, as one example of modelling the transaction as an actor: Reactive Design Patterns — Akka Typed Persistence

3

While saga patterns are useful, I suspect they can be avoided here. (And they should be avoided if you can.)

I’d go through Lightbend’s free Reactive Design course. Because fundamentally it’s hard to give answers on design without real business requirements.

But my first instinct is that you are way too fine grained in your design and that’s what’s causing the issues. Transactions feel a lot more like entities rather than aggregate roots. And thus I’d have each account be an actor and transaction as mere case classes.

This resolves the transactional problem as well. Actors should be able to make decisions given only the message and the current state, which should be the case if the accounts are the actors and the transactions merely data wrapped in messages.

There are some interesting subtleties to consider (what do you use for transaction ids?) and “how do you design the read side?”, since the read side probably has some interesting complexities around closing books. But transactions as actors seems wrong to me: they might even be pure Events rather than Entities.

1 Like
4

Thank you very much @johanandren and @davidogren for your inputs. This gives me already a good starting point and I plan to check the Reactive Design Patterns video and the Reactive Design course :+1:

1 Like