Thoughts on Messages and Events

messages-and-events

Here's how I currently think about messages and events.

A message is a simply piece of data passed from one place to another.

Messages come in two flavours: commands and events.

A command is a message sent by a sender when it wants to instruct another component to perform some task.
* The message is sent one-to-one / point-to-point. It is destined for one receiver.
* The sender knows (at least) the name of the receiver.
* The sender knows something of the domain of the receiver, as it chooses to send the command.
* The sender uses the domain language of the receiver in constructing the command. The receiver knows nothing of the sender.

An event is a message broadcast by a sender when it completes some task or undergoes some change in state.
* The message is sent one-to-many / point-to-channel / pub-sub. Many receivers may receive the same event message.
* The sender does not know the name of the receivers. The receivers know the name of the sender, as they subscribe to events or pull feeds.
* The sender knows nothing of the domain of the receiver. The receiver knows something of sender, as it chooses to receive the command.
* The sender uses its own domain language in constructing the command. The receiver must understand the domain language of the sender.

Extrapolating the above, a "message-driven architecture" really refers to a command-message-driven architecture, where, rather than components communicating using procedure calls, they communicate by sending command messages to each other.

Likewise, "event-driven architecture" refers to event-message-driven architeture where components communicate with each other primarily by broadcasting and reacting to event messages.

Whoever wrote the Wikipedia article on EDA concurs with this interpretation of event notifications as messages:

> "From a formal perspective, what is produced, published, propagated, detected or consumed is a (typically asynchronous) message called the event notification, and not the event itself, which is the state change that triggered the message emission." 

I think your definition and writeup makes sense (in the context it is being used). It is based on the EDA/CQRS/Event Sourcing view on things, in which both it's 'command' and 'event' usually are seen as messages. There is nothing wrong with that (we are using it in Akka Persistence) but I'm using the classic CS definitions of message and event which has an subtle but important distinction between the two: A message can represent an event, but not the other way around (i.e. an event is never a message unless wrapped up as one). This is where the CQRS terminology starts to become a bit misleading, f.e. when you use the word 'event-message-driven', since it can lead you into thinking that all events are messages. This is not true and something we see in a lot of upcoming event-loop frameworks.

The main difference between message-driven and event-driven is that messages are directed, events are not. Messages have a clear (single) destination while events just happen for others (0-N) to observe.

The main consequence is that pure event-driven systems suffer from callback hell precisely because the recipients are anonymous callbacks instead of addressable recipients. Common cures to this phenomenon focus purely on the syntactic aspect—the Pyramid of Doom—while neglecting the difficulties that arise in reasoning about and debugging the sequence of events expressed in the code.