Commands, Events, Requests, and Responses in Message-based Systems

Within MassTransit, messages take the form of .NET types, which can be records, classes, or interfaces. Yet, these messages also carry their own distinct type. This video explores the diverse message types (or stereotypes, perhaps a more fitting term), such as commands, events, requests, and responses. I delve into when to employ each type and explain how these types are produced and/or consumed within MassTransit.
MassTransit
Documentation: masstransit.io/
Discord: / discord
Connect on Twitter:
/ phatboyg

[@drhdev]

Thank you for providing the video content. It was hard to grasp the docs at first but I am 100% on board now after a couple months, and absolutely love MT!

[@ugochukwuumerie6378]

Very useful, thank you

[@goldmund67]

So, if I am understanding this correctly, your 'OrderRoutes' class builds a public http api that in turn uses the RequestClient to 'submit' the order, and then returns an actual Accepted or Rejected response from the Consumer (using ResponseClient) to the api caller.
This is an alternative to the usual design where the http api would 'publish' the order to the bus and return a simple 'OK'. Then the api caller is responsible for separately calling the 'get' api to see if the order was actually Accepted or Rejected. Is that a reasonable take-away?
It makes sense at the edge (the public http api) but am I correct that this would make less sense once the message is hopping along from consumer to consumer (as in a saga)?

[@PhatBoyG]

Correct, there are actually two routes, one POST and one PUT. The PUT just publishes (your alternative) and returns Accepted immediately (not using the request client).
Once inside the service boundary/bounded context, a mix of commands and events are more common, but I still see extensive use of request/response but initiated from sagas instead of consumers (since sagas don't have the call stack sitting around waiting for the response). I cover this elsewhere in a mix of routing slips, durable futures, and regular consumers.

[@Wfmike]

Is it possible for downstream consumers to subscribe to response messages?

[@PhatBoyG]

They cannot, responses are sent directly to the ResponseAddress header added by the request client. They are not published, and published messages are not handled by the request client on the bus endpoint.

[@devmarkmonster]

I've been using MassTransit for a couple of years now. I've always suffixed messages to make sure it's clear what message type they are. Like: *Command *Event *Request *Response. I see you're never doing that, is that intentionally? I'm also always adding a CorrelationId to every message type, is there any good reason to not always include that?