Hi Vaughn, When can we expect "Building a Reactive Process Manager, Twice" implementation working both in Scala with Akka into the github?
On Monday, 11 August 2014 03:27:05 UTC+5:30, Vaughn Vernon wrote: > > None of this stuff is easy to do, and even harder to do right. Your post > gives away the main problem with getting this to work correctly, because > Actor Model and akka-persistence currently supports the first half of A, > but not the second half. In other words, to make the interface rich we not > only need a new set of abstractions, we also need to overcome the direct > messaging nature of actors because it can be limiting in some use cases. > > With the messaging library I am building, currently named Number 9, which > includes both persistence and a process manager, this problem is handled as > follows. Any actor that sends a message may: > > 1. send a persistent message to another actor > 2. send a persistent message to a topic > 3. send a persistent message primarily to another actor, but also to a > topic > > If you have watched any of my presentations on this subject you have heard > this before. I am presenting most of this to the DDD Denver meetup this > Monday night. The title of the talk is "Building a Reactive Process > Manager, Twice". The twice part is because I will demonstrate this working > both in Scala with Akka and also in C# with Dotsero: > > http://www.meetup.com/ddd-denver/events/196746312/ > > https://github.com/VaughnVernon/Dotsero > > I am not sure if the presentation will be recorded. > > Vaughn > > > > On Sunday, August 10, 2014 11:20:52 AM UTC-6, Ashley Aitken wrote: >> >> >> A few things I have noted when re-reading "Exploring CQRS and Event >> Sourcing" http://msdn.microsoft.com/en-us/library/jj554200.aspx : >> >> A. Events can play two different roles in a CQRS implementation: 1) Event >> Sourcing - as a.p provides to persist the state of an aggregate root, and >> 2) Communication and Integration - between bounded contexts and with other >> systems. >> >> B. Not all events in a CQRS system are related to an Aggregate Root: >> "Your event store must have a away to store events that are not associated >> with an aggregate." page 283, so there needs to be a way to inject events >> independently of AR persistence. >> >> C. There needs to be enough default information associated with events in >> the event store to allow (re)construction of various different projections >> after the events were published, i.e. without requiring a priori >> "labelling" of events for specific projections. >> >> These points suggests to me that: >> >> 1. To do AR persistence Akka can get by with a "hidden journal" but for >> full CQRS it may also need to provide access to an Event Store for actors >> (and other entities) to publish events and to filter the whole event stream >> directly as needed. >> >> That said, perhaps a PersistentActor could publish events not related to >> its persistence and just ignore them when rebuilding its state. >> >> 2. There needs to be more transparent metadata associated with events, >> beyond a (possibly optional) persistenceId, that isn't just specified with >> specific projections in mind. I suggest the full type of the event would >> be a good start (to help with the filtering in 1.). >> >> Perhaps also something to help with partial / causal ordering could be >> included. >> >> >> >> >> -- >>>>>>>>>> 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.
