We are currently in the process of writing ES CQRS system using akka persistence. Lately one of the aspects of the akka persistence architecture became hotly debated topic of our design discussions - namely - where are the business rules supposed to be applied in PersistenActor handling of a command.
Martin Krasser states in his blog that "Event sourced processors do not persist commands. Instead they allow application code to derive events from a command and atomically persist these events. After persistence, they are applied to current state." It would help to get some clarification what does the event derivation process entail in general. Is it purely transforming incoming event to one or more events and perhaps tagging on some additional contextual information? Or, does this process also entail running necessary business logic to create the events, which will eventually update the state? Sample implementation of the PersistentActor included with akka persistence documentation (http://doc.akka.io/docs/akka/snapshot/scala/persistence.html) shows how the command handler could be implemented: 1. val receiveCommand: Receive = { 2. case Cmd(data) => 3. persist(Evt(s"${data}-${numEvents}"))(updateState) 4. persist(Evt(s"${data}-${numEvents + 1}")) { event => 5. updateState(event) 6. context.system.eventStream.publish(event) 7. } 8. case "snap" => saveSnapshot(state) 9. case "print" => println(state) 10. } This however is a very simplistic example, which does not answer my question: "where are the business rules applied"? "updateState" handler could be interpreted as such place. On the other hand perhaps it's the constructor of the event (Evt) that symbolizes application of business rules by creating an event from command content. Implications of either interpretation are important to us especially when taking into account state recovery process. Here is what the sample PersistenActor code has for state recovery: 1. val receiveRecover: Receive = { 2. case evt: Evt => updateState(evt) 3. case SnapshotOffer(_, snapshot: ExampleState) => state = snapshot 4. } 5. Is updateState handler's responsibility limited to making changes to state based on events, or is it to apply business rules to the state based on change event? In the latter case that would mean that business rules are also invoked during reply of events while state is being restored. Such interpretation would allow applying business logic fixes retroactively to state, but would also introduce code versioning issues. Any help with understanding of this aspect of the akka persistence architecture would be greatly appreciated. Thanks in advance! -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >>>>>>>>>> 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/d/optout.
