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.
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?