Straight from the tutorial they sent (docs.particular.net/tutorials/quickstart), so this maps
directly onto how they'll phrase the question.
The quickstart's own scenario: a ClientUI endpoint sends a PlaceOrder Command to a
Sales endpoint. Sales processes it and publishes an OrderPlaced Event via
publish/subscribe. A Billing endpoint, having subscribed to that event, receives and processes it
independently — Sales never needs to know Billing exists.
Command:
- Represents a request for a specific action — imperative naming (PlaceOrder, CancelOrder).
- Sent via Send() to exactly one logical destination/handler (point-to-point) — there's always
supposed to be exactly one thing responsible for handling it.
- The sender generally expects it will be acted on (it's an instruction, not a notification).
Event:
- Represents something that has already happened — past-tense naming (OrderPlaced,
PaymentFailed).
- Published via Publish() to zero or more subscribers (pub/sub) — the publisher doesn't know or
care who's listening, or if anyone is.
- The publisher never expects a specific reaction; subscribers each decide independently what (if
anything) to do.
Endpoint = a service/application hosting one or more message handlers. In the quickstart, the
three endpoints (ClientUI, Sales, Billing) share message definitions via a separate Messages class
library referenced by all three — a clean way to avoid duplicating message contracts.
Why this reduces coupling (the tutorial's own framing, worth repeating almost verbatim if asked):
Sales doesn't need a reference to Billing, doesn't call it directly, and doesn't even know it exists.
Billing (or any future subscriber) can be added later with zero changes to Sales.
In NServiceBus, what's the difference between how you send a Command vs how you publish an Event?
tap to reveal answer
Commands use Send() to exactly one logical destination (point-to-point, someone must handle it). Events use Publish() to zero or more subscribers (pub/sub) — the publisher doesn't know or care who, if anyone, is listening.
Give the naming convention rule of thumb for distinguishing a Command from an Event by name alone.
tap to reveal answer
Commands are imperative/instructional (PlaceOrder, CancelOrder — an order to do something). Events are past-tense, describing something that already happened (OrderPlaced, PaymentFailed).
Walk through the NServiceBus quickstart's exact scenario: which endpoint does what, and with which message type?
tap to reveal answer
ClientUI sends a PlaceOrder Command to Sales. Sales processes it and publishes an OrderPlaced Event. Billing, having subscribed to that event, receives and processes it independently — Sales never references or knows about Billing directly.
What is an NServiceBus 'endpoint'?
tap to reveal answer
A service/application that hosts one or more message handlers — it can send/publish messages and/or receive and handle them. In the quickstart, ClientUI, Sales, and Billing are each their own endpoint.
Why does the quickstart's design 'reduce coupling and make the system easier to maintain', in the tutorial's own terms?
tap to reveal answer
Because Sales doesn't need a reference to or knowledge of Billing at all — it just publishes what happened. New subscribers (like Billing, or a future service) can be added later with zero changes to the publisher's code.
If you were unsure whether a given message should be a Command or an Event, what's the single most useful question to ask?
tap to reveal answer
Is this telling one specific place to DO something (Command, imperative, Send), or is this announcing that something already happened, for anyone who cares to react to (Event, past-tense, Publish)? The tense of the name is usually a strong signal of which one you've actually designed.