On Wednesday, 27 August 2014 23:08:27 UTC+8, rkuhn wrote:
In theory if Client sends a command to A which in order to fulfill it will > need to send a command to B then A’s response to the Client will contain > B’s reply in some capacity. Whether there are cases where this structure > becomes impractical is something I cannot tell with my current knowledge. > > > No, I believe there are use-cases where a process manager listens for an > event without having first sent a command to the aggregate root producing > the event. An example could be a process manager listening for any > ItemPicked events and starting a process to check the stock levels and > possibly reorder, separate from the sales process. Again this seems to > require a reliable publish-subscribe facility for events. > > > Yes, this is a good point: I was thinking of ephemeral (per-request) > process managers, for which I still believe that the message flows should > be organized such that the PM does not need to subscribe to events—that > would impose too much overhead. > I understand the concerns about overhead on the read-side but wonder how other CQRS/ES implementations handle this. I asked a question related to this on Stack Overflow and received an interesting answer (explained fully in the comments): <http://stackoverflow.com/questions/25458870/events-on-write-side-of-cqrs-for-saga-process-managers> Your example of a “standing” process is exactly one of those read-side > consumers that we have in mind for the proposed PersistentView replacement. > I apologise if I am misunderstanding what you mean by "read-side" but this PM issues commands so I had assumed it must be on the write-side. If you mean using PersistentView(v2) makes it read-side (I assume one could use PersistentViews on the write-side) then that's ok. Please consider also this diagram, similar to the last one I shared: <https://www.dropbox.com/s/cqfabcjzbbvruuj/annotated-detailed-architecture-overview.png> IMO: Write Side = [1] + [2], Read Side = [3], but I see the similarity of [2] to [3] in a round-about way if the client is included. There is a fundamental difference between commands and events: if a command > is lost then the contained intent evaporates and nothing happens, the > sender will eventually recognize this and retry or abort the transaction. > Yes, I had thought this as well based on what I had read but again from the comments to the Quora answer: "If your commandbus is not reliable, you can use a timeout mechanism (i.e., check for expected result of command after some time), but this requires reliable timeouts." Does Akka have a reliable timeout mechanism (which I assume it means work across crashes)? Thanks, 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.
