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.
Though they have a lot of elements in common, events and messages are meant for different purposes
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.
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.
As opposed to a message , for an event there is no expectation of further processing. An event is the end result of processing a message, and the results reflected in an event are “cast in stone”.
Events can also only refer to a single aggregate. If a message results in changes to multiple aggregates, then multiple events are created by the single message.
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.
Shipment Received from Manufacturer
Defective Item Returned to Manufacturer
Manual Inventory Count
Content of Events and Messages
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.
Leave A Comment