What does an Event actually look like?
Events messages are ultimately machine friendly descriptions of an event transmitted over an event bus. They will always contain the actual event details, and should always (within reason) contain the all the data required to maintain the state of the event. This is because Event Driven Architectures do not have a centralized workflow server that maintains state and is able to rehydrate events from some persistent store. Working with experienced Data Architects, it is my experience that this mind shift sometimes takes a little while to kick in!
In most event schemas, there is a common event header filled with the event metadata, and at least one payload which provides the actual event type specific data.
A diagram showing a typical event schema structure:
As an be seen from a typical event structure, there are a standard set of details normally transmitted with an event. This includes all the contextual information needed for any processing system to understand the state of the event, and the data held within the event.
The separation of the event metadata from the event payload allows any event to be routed (at least at a high level) and understood by the event sinks in the architecture without necessarily needing to parse or understand the contents of the payload.
