Hi Anders, Persisting events in a PersistentActor is not much different than persisting your ORM objects in some kind of service from a separation of concerns perspective. This assumes that your separation of concerns 'concern' is around this area.
I've tried to answer your questions a with some possibilities and experience, hopefully it helps you to move forward. 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? > Have a look at the activator-akka-cluster-sharding-scala, although it is scala code, it gives a good example of using persistence. (it's possible todo the same with java code) > 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... > Using Commands that lead to Events - and store the events for further processing by the views or for replay - keeps the PersistentActor quite well oriented on business logic although some internal state storage may be handy for 'business logic decisions'. A DDD (Domain Driven Design) approach works quite well with kaka-persistence but there are other ways to use it. When you use PersistentViews (these replay events in a separate class) you will be able to use the data in other ways that need no direct integration into your PersistentActor and that allows you to separate things. > * 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... > recovery is running during startup, after that you can use persist and persistAsync without issues. The exact way to go about with recovery is still on my list, possibly the list already contains some answers. (or the documentation) * 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? > Depends on what you mean by actor state. the cluster-sharding sample is doing something similar, that may be helpful to look at. With the events in the event store, you don't need to keep all your state within the actor, you can use PersistentViews to rebuild state for other purposes. > * 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. > It's CQRS / DDD Approach. Some of that is more elaborate in code, but very flexible when your Commands needs more complex logic. > > 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? > Event Sourcing storing all your changes instead of your current state, that storage is organised via persist and replay, but you don't have to worry about the actual storage and storage structure of these events. > > I hope this question is not too general. > Hope to hear your findings while you progress. Kind regards, Olger > > 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.
