Those new to Event Driven Architectures often treat the words “events” and “messages” as interchangeable.  Though they have a lot of properties 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) – UpdateInventory or CreateUser.

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.  Events are usually named in the past tense for the aggregate whose state changed, such as InventoryUpdated or UserCreated.

Events are lightweight in that they do not include all aggregate data – their payload can either be just the ID of the aggregate that changed, or the ID and just the properties that have changed so the receiver can update their cached copy.  If the aggregate is small (less than 5 properties including the ID), I will bend this rule and include the entire aggregate.

An important difference between events and messages is that there is no expectation of further processing for an event.  After the event is published it can be ignored by all systems without any harm coming out of it.  A message, however, carries the assumption that something somewhere will process it.

Another difference is that messages can affect 0 or more aggregates while an event reflects a change to exactly one aggregate.  The Use Case that is executed in response to a message can decide what aggregates need to be updated, possibly resulting in no changes at all.  Each aggregate that is created, however, should publish an event stating changes that were made.

You may have heard the terms Event Sourcing and Event Streaming.  The events I’m describing here are appropriate for both.

 

 

My Story

Hi, I’m Brad Irby. Since I began my career in Software Development 30 years ago, nearly every project I’ve worked on has been with existing code, not building from scratch. In working with companies like General Electric, Wells Fargo,and Bank of America, I have learned how to work with large legacy systems, and bring them up to date by injecting current development techniques into existing code. In fact I’ve done it so often, Addison Wesley ask me to write a book about it.

Learn More