ylorph
Problem: Patterns for Command Processing & Responses
- Do commands have responses ?
- What do do with errors ?
- Are they Request/Response ?
- Are they Fire & Forget ?
- What about client issuing a command and needing a result in some projection ?
Partial idea here : https://github.com/ylorph/RandomThoughts/blob/master/2019.10.29.CQRS.md
In general it is easier to make something that is designed as asynchronous behave in a synchronous manner than the reverse (if you add a "while you wait" wrapper)
Designing commands to be asynchronous tends to lead down the path of fire and forget but this is not absolutely mandatory - you can have an asynchronous command and poll for response(s).
If you allow chaining I don't see it as inherently wrong to have a command then chain a query - i.e. "Apply the command and then give me a current view of some states" but this might be done at the UI level with some refresh triggering (like SignalR).
It's the "Behave in synchronous manner" that's difficult for me. It's higly dependent on the requirements, expectations, limitations of the client . with the chaining DoCommand(cmd).DoQuery (query) what if the client is a browser app => it might want to get an update a soon as posiible to wait for the read model to be update, get the read model directly if's fast enough, ... So that kind of chaining must be done in the application layer ?
The usual thing with web apps and latency is to pretend on the client side (i.e. show the data as you would expect it to be if the command succeeds) until the consistency catches up.
(You have to assume the command is more likely to succeed than fail)