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. > > >> 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. 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)? > 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. 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. 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.
