Those new to Event Driven Architectures often treat the words “events” and “messages” as interchangeable.  Though they have a lot of elements in common, they are meant for different purposes and have different properties.  The most common definition I get for the two words is that of a message.

A message is a request from one system to another for an action to be taken.  The sender may or may not know what process is going to receive and process the message, but there is an expectation by the sender that it will get processed somehow.  The sender includes in the message a full payload of data that needs to be processed, and formats that data appropriately for the receiver to process (i.e. a contract exists between the two systems).  Naming of a message is usually done as a request (I like to imagine putting “please” in front of the name) – ReceiveInventoryFromManufacturer or CreateUser.

The key idea to remember is that messages are a request for something to happen – it hasn’t happened yet, and may not happen if the request violates any business rules.

A message carries the assumption that something somewhere will process it.  This is the beginning of a process that will probably result in the change of data somewhere in the system.

A messages can also affect more than one aggregate.

An event, on the other hand, is a notification that data has been processed and some objects’ state has changed.  Though events frequently are created after processing a message, that is not required.   The data change could have been made in response to any appropriate request by any system.

Events are usually named in the past tense for the aggregate whose state changed, such as InventoryIncremented or ProductCreated.  When naming your events, though, don’t be too generic.  Something like InventoryUpdated is not descriptive enough.  When reading a list of events, you should have a pretty good idea of what happened.

Look at the following examples for events that all affect inventory levels and see which one gives a better idea of what is going on.  Note that the events on the right are all named in past tense, and reflect the business idea that is happening.

Since events and messages have different purposes, they will contain different embedded information.

Messages contain any information necessary to perform the requested action.  For example, a message may contain the ID of the user that requested the operation, the ID of the business entity that will be affected, and the new value of any properties.

Events will only contain the ID of the item affected, and the data that was changed. They should be lightweight in that they do not include all aggregate data; just the data that changed.   If the aggregate is small (less than 5 properties including the ID), I will bend this rule and include the entire aggregate.

When planning what data to include in the event, remember that it should be usable as an event source.  An Event Source is a stream of changes made to a particular object that, when added all together, will result in the current state of that object.  In a true Event Sourcing system, the only data persisted will be the stream of events so if any data is excluded from an event, the change will not be reflected in the final state.  In many systems, the current state of an object is often saved in a database and the stream of events is only used as an historical record of how the entity got to the state it is in.  However, event content should be planned as if no database exists.