14

Two enterprise integration patterns are the command message and the event message. I am working on a system in which we use messaging not only for integration with other systems, but for internal communication between services. It's supposed to be an eventually consistent system, and services are supposed to be ignorant of each other (with exception to a couple special-purpose services). As such, we try to avoid things that feel like remote procedure calls (RPC or RPI). We have a bus and message-oriented middleware system, and all messages are broadcasted.

We tend to name our messages as events, that is, as a phrase in the past perfect, e.g. PurchaseOrderShipped. However, the events are often added only when some other services needs to know about them, and in the beginning, often only one service cares. Moreover, sometimes that service emits an event as a result, which is listened to by the first service. Thus if I were to diagram the interaction, it would look much more like the diagram for the command message in the link above (or even the RPC diagram) than the one for the event message, though once again, this is not actually implemented with direct messaging but broadcast on a bus. Add to that the fact that I have recently seen some messages being added that are named as commands, that is, a phrase in the imperative, e.g. BillShippedPurchaseOrder.

The odd thing is that the names of the messages and the way they flow are not changes by whether it is named as an event or as a command. So how does one determine whether something should be a command message or an event? Is this just a difference of semantics and naming, or is there an actual implementation difference between command and event messages? Given that all our messages are broadcast, does that mean than none of them are truly command messages?

Kazark
  • 1,810
  • 1
  • 17
  • 37

2 Answers2

15

There is a subtle, but important difference between commands and events. A command has a presumption of a response whereas an event does not presume a response, it's merely a statement.

To be less abstract:

ShipOrder is a command and the sender of ShipOrder will likely expect a response of some sort.
OrderShipped is a declaration and the sender is unlikely to expect a response as GoodJob! is a useless response in this example.

If you're designing your systems to only expect event messages, then it doesn't necessarily matter to the system design what you call the messages. Developers may get confused by the name of a message, but the systems will respond just fine regardless of what convention you follow to name things with.

But it doesn't sound like your fellow developers are following the event-only message model. If services are expecting responses to the "event messages" they are sending out, then they are really sending out command messages. It's not a big deal, and I can think of many cases where commands such as requests for information would be required. But you'll have a semantic headache if you expected to only see event messages.

Broadcasting messages doesn't really have an impact on whether a message is a command or an event. Generally, you don't broadcast commands as it duplicates effort. But there's nothing to say you couldn't. Early network protocols broadcasted every packet and the receivers had to be intelligent enough to know when to ignore messages packets that didn't belong to them.

  • How do you implement `request for information` functionalities? It seems natural to use something like `getUserInfo(uid)` which is a command message excpecting a response. I know that command messages introduce coupling, but sadly in this case, I don't see how to implement it with event messages. Or it is just fine to stick to command messages on some occasions like this? – du369 Sep 14 '18 at 15:24
  • @du369 Sorry, but I'm not quite following your question. It sounds like you're attempting to create a command but using events? –  Sep 14 '18 at 21:14
  • Yes, pretty much that. In the [link](http://bill-poole.blogspot.com/2008/04/avoid-command-messages.html) provided in Lee's answer, the same functionality is implemented in two different ways. One is using `CancelPolicyRequest` message which is a command. The other approach utilizes two event messages, namely `InvoicePastDueNotification` and `PolicyCancelledNotification`. So I am wondering if it is possible to chage commands like `getUserInfo(uid)` to event messages style and how am I supposed to do that. – du369 Sep 15 '18 at 02:47
  • 1
    @du369 Something, somewhere has to perform the `Action` associated with the command. There are two steps associated with a command. 1) Is the command needed (e.g. policy expired), and 2) execute the command (e.g. cancel the policy). If the `Actor` that determines if the command is needed AND can execute, then that `Actor` is able to send event messages. Otherwise, whatever determines that the command is needed is required to send a command event. –  Sep 16 '18 at 13:06
7

An Event message is something that has just happened. You are notifying of the event that has just happened.

A Command message is a message that expects something to be done. It may or may not expect a response.

When to use what comes down to coupling and the difference will only emerge over time as the systems evolve. Favoring events over commands results in less coupling. The emitter of the event does not care about the consumer. In a command pattern the caller knows and is therefore dependent on the existence of the provider.

Bill Poole suggests avoiding command messages all together: http://bill-poole.blogspot.com.au/2008/04/avoid-command-messages.html

http://bill-poole.blogspot.com.au/

Lee Simpson
  • 71
  • 1
  • 2
  • Lee, thanks for your answer, but I do understand the theory behind the definition of each. My question is how to apply this in real life---when to notify that something has happened, which often results in something being done, and when to request that something be done. – Kazark Jan 07 '15 at 13:40
  • I think it comes down to coupling and the difference will only emerge over time as the systems evolve. Favouring events over commands results in less coupling. The emitter of the event does not care about the consumer. In a command pattern the caller knows and is therefore dependent on the existence of the provider. Have you read the articles by Bill Poole? – Lee Simpson Jan 11 '15 at 17:16
  • Lee, thanks, that's helpful; in fact, I suggest you edit content from your comment into your answer, including a link to the Poole articles (which I'm not sure that I've read). – Kazark Jan 12 '15 at 21:04