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-sourcingfor
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!
On Mon, Apr 14, 2014 at 7:44 PM, Richard Rodseth <[email protected]> wrote:
> 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.
>
>
> On Mon, Apr 14, 2014 at 9:46 AM, Jakub Czuchnowski <
> [email protected]> wrote:
>
>> 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
>>
>> --
>> >>>>>>>>>> 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.
>>
>
> --
> >>>>>>>>>> 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.
>
--
Cheers,
Konrad 'ktoso' Malawski
hAkker - Typesafe, Inc
<http://www.scaladays.org/>
--
>>>>>>>>>> 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.
