There is quite a terminology collision among these terms happening in backends. This short note concisely explains what is what, where, and what for.
Contents
- Event-Driven Architecture (EDA)
- Event Sourcing
- Event Storming
- Overview Diagram
- References
Event-Driven Architecture (EDA)
This is an optional part of the application-level architecture [1]. It defines one of the ways allowing an application components to communicate with each other (see also my When Bother with Events).
The event, in this realm, is a means of communication between otherwise decoupled (independent) components.
The events are passed via event buses [2] or message brokers [3].
Messaging
In EDA events are the same as messages, the application-level tools, not domain-level notions. The messages and events can be used interchangeably in the application context.
Disambiguation
At backends it is simpler to use term message to avoid collision with a number of other event terms used there. In front-ends events are widely used, however the nature - means of decoupled communications among the application components - stays the same. People need a convention to understand each other. Use this one if see convenient.
Event Sourcing
This has nothing to do with communication between application components.
It is a logical persistence model that suggests recording a historical sequence of domain entity states. Events here are problem domain happenings — records of different types of domain data.
They are persisted in the application database in an append-only manner (they say, "a log of domain events"). It contrasts with the more common approach of recording only the latest domain-entity state.
They resemble a lot "time series" in statistical meaning with the very similar purposes. They are used to reconstruct the state of domain entities at any desired point or a period in time.
Event Storming
Event Storming is the problem domain events [^3] discovery method, used in requirements engineering, came to us from Domain-Driven Design (DDD).
They are used for domain and application modeling. These events may or may not be further stored as history of domain event states at the application database becoming events in the Event Sourcing meaning. And they may become a payload in EDA messages which unpleasantly clashes with "E" (events) of the EDA.
Finally, this completely clarifies the matter.
Overview Diagram
Add the SVG Navigator extension to your Chrome to comfortably view the diagrams with zoom and pan in the separate tab.
References
[1] See the definitions of the application (service) level and its place in a multitier (N-tier) software architecture used in complex products. For wider context see Fowler's Patterns of Enterprise Application Architecture (2002), p.30, Service Layer; Domain-Driven Design (2003), p. 68, Layered Architecture.
[2] In NodeJS ecosystem eventemitter3, emittery, mitt. In browsers see DOM, events interface that principally behave the same way or Server-Sent Events (uses persistent HTTP connection as kind if event bus).
[3] [RabbitMQ](https://www.rabbitmq.com/docs) (queues and streams), Apache Kafka (pub/sub via streams), NATS (queue-like topics and streams) and many others.
