Hi Ashley, 4 jun 2014 kl. 04:21 skrev Ashley Aitken <[email protected]>:
> > Hi Roland, > > Thank you very much for your reply to my post. > > On Wednesday, 4 June 2014 04:40:35 UTC+8, Akka Team wrote: > > 1. Distributed and Resilient Pub-Sub within Akka > > It seems to me that a resilient pub-sub is a key component for a CQRS > approach and for a distributed system this would also need to be distributed. > > Why do you assume that PubSub plays a key role? CQRS means that events flow > reliably from the write model to the read model, which most naturally occurs > via the journal, i.e. using replay streams (upcoming feature in the Akka > Streams project) or Views. > > PubSub seems common in implementations of CQRS. As you suggest I don't think > it is necessary but I don't see Views (currently) as being able to fulfil > this role due to the limitation of tracking a single processor (and I'm not > familiar with Akka Streams). > > I am really just trying to learn how best to implement the reliable flow of > events from the write model to the read model with this need to allow the > view model to subscribe to a category of events not just those from one > processor. Please see denormalisation below. > > I am sorry if I am misunderstanding CQRS or Akka Persistence. I can see how > Views could be somewhat useful for constructing different read model > representations of a *Processor (I think the technical term may be different > projections) but I am not sure if this is enough. You are right in that the current View functionality is not enough, we need to add the ability to aggregate event streams. You could probably call that some form of PubSub, but it is a very specific one: there is exactly one publisher for each fully persistent topic, and all subscribers get all events starting at a point chosen by each individually, but they are not coupled as to when the delivery occurs (i.e. every one in its own time). Therefore I tend to think of it more as a point-to-point communication model instead of the richer generic PubSub semantics. > > > I believe the event system in Akka is currently per-node and not resilient. > What is the current best practice for resilient distributed pub-sub for CQRS > with Akka? > > What do you define as “resilient” in the context of PubSub? > > Good question and as a novice I’m not trying to redefine terms, it’s just > what I read about other PubSub system. I took it to mean there was some sort > of guarantee about delivery (which may mean enough persistence to enable the > system to complete delivery after a restart etc). > > Of course, this is precisely what Akka Persistence does so it could be used > to implement a resilient and distributed PubSub system. I have been trying to > understand if DubSub or DistributedPubSubMediator would be appropriate for > this task and welcome any advice. With the scheme described above it should be possible to reliably disseminate event streams to multiple subscribers. The crucial point is that the mode of dissemination is very specific and not configurable; for generic PubSub I would find it hard to specify what “resilient” shall mean. > > > 2. Process Managers > > What is the best approach to implementing process managers (for sagas) in > CQRS with Akka. I am quite a novice in this area so the answer may be > obvious but I'm wondering about whether it's best to use singleton actors, > processors, eventsourced processors, finite state machine etc. > > It seems to me that process managers in a distributed system would also > require distributed and resilient pub-sub (as discussed above) to work well. > > A Saga is typically a persistent actor (currently EventsourcedProcessor, soon > to be renamed to PersistentActor for brevity and consistency) that > communicates with specific other actors representing aggregate roots, I see > no need to involve PubSub in this process. What you might encounter is > ClusterSharding for spreading out your ARs across a cluster. > > Thank you for explaining that. However, my understanding of a Saga is that > it needs to be listening / tracking events of multiple ARs even across > multiple bounded contexts and that PubSub was a good way to do this because > it allowed the decoupling of the Saga from the AR. > > So a simple example would be a FundsTransferSaga that sent a command to one > BankAccountAR to withdraw some funds and then waited until it recognised an > event indicating those funds had been withdrawn before it issued a command to > deposit them in another BankAccountAR etc. > > My understanding was the best way to do this was using PubSub so that the > bank account BankAccountARs were decoupled from the FundsTransferSaga and > vice-versa. I don’t see how it could be accomplished appropriately with > simple actor communication (unless using the ask anti-pattern)? No matter what we do, we cannot win ;-) “ask” is not an anti-pattern, it is a pattern that we have seen overused. Therefore we have often advised against it, but it still is a very common and useful way to conduct a conversation (just like we do right now). The decoupling you desire between the Saga and the BCs goes one step too far: it will have to have a means of looking up the current point of contact for the involved ARs, but once that is established the Saga will need to communicate with them and there is no need to hide this fact. What is needed is therefore service discovery and not PubSub. > > > 3. Denormalisation of Views > > I've discussed this previously with Martin and others as a result of the > restriction of Views to track one processor. Ideas like using a database > with triggers within the view model to update denormalised data were > suggested but I am wondering if this is the best practice for now? > > Can you explain what exactly this question means? It seems that it is > targeted purely at RDBMS usage, but I might be misunderstanding what you are > getting at. > > My understanding of a classic use of the view model is to denormalise the > view to enable fast queries. So for example, what I would like to achieve is > a denormalised view of a collection of Employees in a Department so the > client could query and get a listing of all employees in a department with > the details for each employee. > > EmployeeView actors could each track and project the state of their > EmployeeProcessor. DepartmentView could track and project the state of the > DepartmentProcessor as a collection of Employee identifiers. However, I am > not sure how I would implement DenormalisedDepartmentView (as explained > above). > > What I believe Martin suggested as one possible implementation (until Views > like DDV can track multiple Employees) was to have EmployeeView in a database > and whenever one was updated it could trigger an update to the > DenormalisedDepartmentView. That seemed possible to me, although it coupled > the EV to the DDV. > > Again, I am really just keen to find out how best to do these sort of > denormalised views with Akka Persistence, if possible. I don’t wish to use > database triggers. DistributedPubSub is the way I understand it is commonly > done in CQRS. With the DDV subscribing to events published by the SVs. This comes back to aggregation as discussed above, and I agree that this is the prototypical use-case for such a feature. This is currently not well supported, but we are working with full steam on getting the stream-based infrastructure in place. > > I am very new to DDD / CQRS and Akka Persistence so I could be > misunderstanding all of this (but I do seem similar discussions elsewhere). > I am starting out on a new project and I am trying to get most of this sorted > out in my head before I get too far into the implementation. > > Thanks again of your post. Thanks for raising these points and explaining the use-cases, this is also helpful for us! Regards, Roland > > Cheers, > Ashley. > > > > -- > >>>>>>>>>> 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. Dr. Roland Kuhn Akka Tech Lead Typesafe – Reactive apps on the JVM. twitter: @rolandkuhn -- >>>>>>>>>> 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.
