Hi, This is more of a design-pattern question than a technical one:
I've been looking at the event-sourcing implementation in the Akka persistence module as a possible replacement for our current Akka/event-sourcing setup. In our existing framwork we're going with the following pattern: CommandHandlers -> EventStore -> Views/Sagas. Each individual command handler, view, or saga are implemented as an actor. Looking at the implementation and examples from Akka persistence it seems to lean towards a pattern where a single actor receives commands, validates and executes, stores resulting events to the journal and alters internal state to reflect changes (and manages recovery on restart). In my mind this would result in a situation where you have one actor per aggregate managing the above functions, which would load it with quite a lot of complexity and business logic. You could off course delegate some of functions to other actors (such as using channels to dispatch events to views), but you're still left with a situation where the same actor receives commands and manages the journal. It would be interesting to learn what implementation patterns people are following with regards to akka persistence (and if my above assumptions are correct)? -Andreas -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: http://akka.io/faq/ >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/groups/opt_out.
