Thank you both for your replies. This is exactly the information I was looking for. I wanted to know if business logic should be applied in the command handling portion of the event processor before the event is generated, or after the fact. What was throwing me off was a statement I read in akka persistence doc explaining role of the journal: "*Jo**urnal**: A journal stores the sequence of messages sent to a persistent actor.*"
Since event processor does not store commands, and journal's role is to *store messages sent to persistent actor*, this convinced me that events stored in journal are simply messages derived from commands before any business logic is applied. Apparently my assumptions were incorrect. This clears in my mind what should be happening during state restoration process when the events are being replied from journal. Namely, state is simply updated using events replayed from journal w/o running them through any business rules. Fair enough. Cheers, ~g On Thursday, July 31, 2014 2:31:55 PM UTC-4, George Wilk wrote: > > 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.
