4

Following this example: https://msdn.microsoft.com/en-us/library/jj591569.aspx (Figure 3)

How it fits in a http application?

The user should perform a http request to the PlaceOrderController, which will send a PlaceOrderCommand, but how would the Order Process Manager answers the "9. Order Confirmed" to the user? How is the controller aware of that, in order to return this info to the user?

Thanks

fj123x
  • 6,904
  • 12
  • 46
  • 58

3 Answers3

4

You simply don't answer "Order Confirmed" immediately. Take a look at how Amazon and other shopping sites do it: Upon Order submission, you just receive an "Order Accepted confirmation (e.g., HTTP Code 202 Accepted). When the actual order has been handled by the order process manager, an "Order Confirmed" notification on a separate message/channel (e.g., email) is sent to the user.

Alexander Langer
  • 2,883
  • 16
  • 18
  • and how is shown the message "your purchase was successful" in the web? :/ – fj123x Sep 16 '15 at 07:19
  • 3
    @fj123x Maybe by sending an email or maybe the page polling the backend or by sending a message via websocket – Yugang Zhou Sep 16 '15 at 07:23
  • polling where? a controller which act as "inbox" in order to get all messages last the previous http request? (is not correct wait in the first request until the process manager has finished?) – fj123x Sep 16 '15 at 07:36
2

@Hippoom points you to the right direction.

CQRS Journey (what are you reading) says:

The team later replaced this mechanism for checking whether the system saves the order with an implementation of the Post-Redirect-Get pattern. The following code sample shows the new version of the StartRegistration action method. For more information about the Post-Redirect-Get pattern see the article Post/Redirect/Get on Wikipedia.

[HttpPost]
public ActionResult StartRegistration(string conferenceCode,
OrderViewModel contentModel)
{
...
this.commandBus.Send(command);
return RedirectToAction(
"SpecifyRegistrantDetails",
new { conferenceCode = conferenceCode, orderId = command.Id });
}

The action method now redirects to the SpecifyRegistrantDetails view immediately after it sends the command. The following code sample shows how the SpecifyRegistrantDetails action polls for the order in the repository before returning a view.

[HttpGet]
public ActionResult SpecifyRegistrantDetails(string conferenceCode, Guid orderId)
{
var draftOrder = this.WaitUntilUpdated(orderId);
...
}

The advantages of this second approach, using the Post-Redirect-Get pattern instead of in the StartRegistration post action are that it works better with the browser’s forward and back navigation buttons, and that it gives

Here we are talking about eventual consistency of milliseconds or a few seconds in the worst case. So a P-R-G pattern fits perfect.

Anyway, here and here there you can read articles about eventualy consistency UI than can help you.

POST COMMENT EDIT:

Here Udi Dahan says:

When should you avoid CQRS?

The answer is most of the time.

Here’s the strongest indication I can give you to know that you’re doing CQRS correctly: Your aggregate roots are sagas

So, I think your problem is not discover how CQRS works for HTTP application. Your problem is that with the process and use cases about you are questioning you should avoid CQRS.

jlvaquero
  • 8,571
  • 1
  • 29
  • 45
  • "Here we are talking about eventual consistency of milliseconds or a few seconds in the worst case. So a P-R-G pattern fits perfect." ok, so: 1. you submit an order (P) 2. you redirect to the G 3. what happens if the order is not confirmed yet (because latency of third parties, whatever), should you repeat the R (redirect to G) until there is a result? – fj123x Sep 16 '15 at 22:33
  • 2
    If you want an immediate response, you should consider synchronous command handling instead. Otherwise, use some kind of asynchronous notification system (such as the message notification here on StackOverflow). – Alexander Langer Sep 17 '15 at 05:57
  • are synchronous command handling correct in cqrs/es applications? I read https://lostechies.com/jimmybogard/2012/06/26/eventual-consistency-cqrs-and-interaction-design/ and they say "If you have users that have to wait to have the view model updated to see their results, you have built the wrong user interface. Results should be immediate. Did you receive my command or not? Yes or no? What is the status of my command? This is the interaction you should have." and they say not. btw: There are some cases which the info cannot be faked (like a "spin to win, etc") – fj123x Sep 17 '15 at 07:29
0

Your Web/REST api is independent of your domain model but maps to it based on your use cases and user agent needs. One way to go is the submit a "job" and then poll the job for progress. There are many tradeoffs to consider. For example depending on your infrastructure sending a notification is probably the best way to go. If you want REST/HTTP you can try this:

User Agent:

POST /jobs/registrations
..content..

Origin Server:

HTTP/1.1 303 See Other
Location /jobs/registration/<some-job-id>

User Agent:

GET /jobs/registration/<some-job-id>
..content with job status..
Derick Schoonbee
  • 2,971
  • 1
  • 23
  • 39