How to determine if a message should be a command message or event message?

Question

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?

Answer 1

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.

Answer 2

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/