It is still not a trivial task to do this and keep your business logic clean and separated from the persistence part. From my experiences the following makes things more complex:
- It is not necessarily a 1:1 relationship between commands received and state changes. One received command may result in several state changes (e.g context.become(..) behaviour changes, initiating timers which will expire some time after message processing as well as regular state changes in instance variables. But also the opposite may be true. Perhaps only 1:100 received message (via the onReceiveCommand call) will yield a state change, making command sourced persistence inefficient when recovering. - State change may not be easily identified by inspecting the message type (i.e Cmd versus Evt vs Query). Instead it may be necessary to evaluate message properties to identify state changes. The approach I currently take is to encapsulate state within private classes and allow access to these via regular getters/setters from business related code. Then within the private state class I do the akka persistence related code. At least it makes the business code more clear, although the persistence part of the code may still be very verbose, in particular when dealing with recovery of timers and context.become behaviour. But then again, I am limited to using Java at the customer's site, so I guess that also adds to the verbosity On Thursday, October 16, 2014 10:38:49 AM UTC+2, Anders Båtstrand wrote: > > Dear Akka users > > I am currently adding Akka persistence to an existing (java) Akka > application, and have some questions. The example in the documentation > seems too simple for me, and I wonder if there are any examples of bigger > application, with more complicated actors, out there. Any best practices > (with examples bigger than a counter)? Any patterns you have used with > success? > > Some questions: > > * How do you achieve separation of concerns in an UntypedPersistentActor? > It seems to me that the business-logic will be heavily mixed with logic to > determine if the the message received should be persisted or not. I am > searching for a way to separate business-logic from the persistence-part... > * How do you reuse procedures (with getContext().become(...)) between > onReceiveRecover and onReceiveCommand? I could call recoveryRunning() every > time I need to do something different, but especially with persist(...), it > just makes for a lot of code... > * We are trying one approach, in which we encapsulates all actor-state in > an object which handles all the persistent bits, but (again) the code base > grows enormously. Anyone else tried this? > * I could receive commands, and for all state-changes create a new event, > which is persisted (and then calls the same method as onRecieveRecover). > That seems (again) as a lot of extra code. > > I do realize that this might be how it has to be, as Event Sourcing is > complex. Do you have any patterns for separating the persistence logic from > the business logic? Or are they really in-separable by nature? > > I hope this question is not too general. > > Kind regards, > > Anders Båtstrand > Oslo, Norway > -- >>>>>>>>>> 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.
