Akka Event Sourcing – how to create Actor per Entity

akkadesign-patternsdomain-driven-designevent-sourcing

I was reading Akka Persistance documentation and it says that Akka is good for Event Sourcing.

Imagine I have a User entity. Each user is defined uniquely with ID and has some properties and some business rules around how they can be altered. Also, some modifications of User properties can have some async side effects, like notifying another system that a User has been created. Very basic DDD setup.

So from what I understand Akka PersistenceActor is good for keeping the current state of the User, accepting modifications 1 by 1, so nothing can slip inbeetween.

So if I model these users with PersistenceActors where I create an actor per user, but the number of users is way too big to keep them all (or even load them all) into the memory, how do I deal with creating/stopping actors, their persistence/etc..

It seems like quite a complicated task to bear manage. But if I do not do that, what else can PersisteceActors be good for?

Best Answer

You want to look at Akka Cluster Sharding. This complements Akka Persistence to distribute the instances that are currently kept in memory in the cluster and manage their lifecycle.

Also keep in mind that Akka is - by design - a rather low-level toolkit. For an easier getting started experience with event sourcing and cqrs based on Akka, you might want to look at higher-level framework, like Lagom Persistence (Java & Scala) or Fun.CQRS (Scala).

Related Solutions

Event sourcing, one event, state of two aggregates changed

When transferring it's different - two aggregates must be modified by one MoneyTransferred event.

Transferring money is a separate act from updating the ledgers.

MoneyTransferred
AccountCredited
AccountDebited

The exercise that finally broke this loose for me was realizing that AccountOverdrawn is an event, it describes the state of the account without regard to the other participants in this exchange, so there must be a command run against an account that produces it.

You can't reasonably derive state like AccountOverdrawn from the read model, because you can't possibly know if you have seen all of the events yet -- only the aggregate itself has a full view of the history at any given moment.

The answer, of course, is right there in the ubiquitous language -- accounts are credited or debited to reflect the bank's obligations to its customers.

Allright, but it means I should use AccountCredited and AccountDebited events for deposits and withdrawals as well, so I only register not the cause of change, but the change caused by some other action. If I would like to reverse the action I couldn't, because not all of the events are registered.

I'm not entirely certain that follows, because you do have (for cases like this one) a natural correlation identifier, which is the transaction id itself.

Second thing - it means i need to use something like saga.

Slightly different spelling: you need something like a human being dispatching the right commands.

There are at least two ways you could do it. One would be to have a subscriber listening for MoneyTransferred, and dispatching the two commands to the ledgers.

Another alternative would be to track the processing of the transaction as a separate aggregate -- think of it as a checklist of all the things that need to get done since a transaction occurred. So a MoneyTransferred event handler dispatches ProcessTransaction, which schedules work to be done and checks off what work has been completed.

Best Answer

Related Solutions

Event sourcing, one event, state of two aggregates changed

Related Topic