DDD/Eventsourcing with Akka Persistence

[Jakub Czuchnowski]

Hi everyone,

This is my first post on this group so for starters I'd like to thank the Akka team for the awesome product. Love it.

I was just going through the Akka Persistence documentation and I was wondering how to achieve the event sourcing functionality as it is used in Domain Driven Design. For example, when I get a command to modify an aggregate with some particular id, is it a good idea to instantiate an actor for that aggregate and additionally a processor to retrieve the current state and then persist the new event? I guess my insecurity comes from the statement in docs that "A processor must have an identifier that doesn't change across different actor incarnations.".

Additionally how this solution will be represented in MongoDB? Will all the events for the aggregate type will land in the same collection?

Sorry if I'm asking these qestions too early in my own research and I could have found a solution myself, but maybe someone has already done it and could shed some light on this particular use case.

Thanks,

Jakub

[Richard Rodseth]

Take a look at the "cluster sharding" activator template, and some of the answers to my questions on this group. I think it would be nice to have an Activator template for DDD/Akka Persistence that didn't depend on a cluster.

--
>>>>>>>>>> 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 akka-user+...@googlegroups.com.
To post to this group, send email to akka...@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[Jakub Czuchnowski]

Thanks Richard,

I'll definitely look into that. And it just might happen that the new activator template will come out of this :)

Jakub

[Konrad Malawski]

Hello Kuba,

Firstly, thanks for the Akka love! We <3 you too ;-)

Back to your questions:

Yes, the Actor would represent an Aggregate; and yes, it's a good idea to spin up Actors for specific ID's, handle the command / event in it, and emit more events signifying some business logic was performed on it.

You'll want to have a look at EventsourcedProcessor http://doc.akka.io/docs/akka/snapshot/scala/persistence.html#event-sourcing for driving such interactions (you can easily persist() events from it too).

The sentence you refer to from the docs handles this scenario: Your processorId is "crazy-bob-222", and the processor fails (or you turn off the system) - when the Processor recovers, it should replay events for "crazy-bob-222",

so from the outside it'll seem as if there never was a failure - all the events for this processorId will have been replayed in the Processor, so it's up-to-date again. By incarnations we mean if you create new Processors that should

work for the same user ("crazy-bob-222"), you should use the same processorId - which causes the replay to happen.

As for the Journal question. It's actually up to the Journal plugin where to store stuff. (Journals have pluggable implementations - for mongodb you'd use a community provided one from this list: http://akka.io/community/ ).

The most common approach is indeed keeping a collection for "akka events", in which the processorIds would be used as keys - so if we're replaying events for "crazy-bob-222" the plugin would do a select for these documents / rows with this ID.

If you'd be able to build up an example Activator template that would be completely awesome! If you need any tips let us know :-)

I hope this helps, happy hakking!

--

Cheers,

Konrad 'ktoso' Malawski

hAkker - Typesafe, Inc

[Richard Rodseth]

Here's a pertinent reply from Patrik to me:

On Mon, Mar 3, 2014 at 4:07 PM, Richard Rodseth <rrod...@gmail.com> wrote:

I haven't looked at the sources, but it seems that passivation and clustering could be orthogonal?

yes, indeed, the high level description:

- all messages are sent via the Manager actor, which creates child Aggregate instances on demand

- when receiving a message the Manager extract the Aggregate identifier from the message

- the Manager creates a new child Aggregate actor if it doesn't exist, and then forwards the message to the Aggregate

- the Aggregate can passivate itself by sending a Passivate message to the parent Manager, which then sends PoisonPill to the Aggregate

- in-between receiving Passivate and Terminated the Manager will buffer all incoming messages for the passivating Aggregate

- when receiving Terminated it will flush the buffer for the Aggregate, which can result in activation again

The PoisonPill can be replaced with some other custom stop message if the Aggregate needs to do further interactions with other actors before stopping.

The number of characters to implement this is probably less than what I have used in this description :-)

[Jakub Czuchnowski]

Thank you guys for the information. I'm going to write some code now and get back with more questions :)

Jakub