Loading content
Event-Driven Architecture (EDA) is an architectural approach that focuses on the generation, transmission, and processing of events. In EDA systems, components communicate through events generated by an event emitter and processed by one or more event handlers. This approach promotes decoupling of components and enables a responsive, scalable, and flexible s…
Use this profile to understand the building block briefly, place it in the model, and switch to the 360° assessment when needed.
Theoretical construct: explains a term, principle, or mental model.
What organizes, connects, or makes decisions possible.
Event-Driven Architecture describes systems where domain changes are published as events and processed by other parts, instead of forcing direct calls between every component.
The approach emerged in software architecture and distributed systems from the problem that tightly coupled components are hard to manage when change, load spikes, or different response times matter. Events shift coupling away from direct calls toward observable state changes: a producer reports that something happened, and other parts react independently. That makes integrations, user interactions, and domain process steps easier to connect flexibly.
Think of EDA as a notice board with reaction chains. A source creates an event and places it on an event channel. One or more handlers pick it up, inspect the type, and carry out a local response. That response can create further events. The architecture separates trigger, transport, and processing; coordination emerges from the sequence of events rather than from tight direct calls.
An observable domain change that other components can react to.
A component creates and publishes the event without hard-wiring its later processing.
The channel transports events between the source and the processing units.
A handler receives an event and turns it into a local domain response.
Triggering and processing are separated so that changes in one part do not immediately bind all others.
EDA is useful when multiple systems should react to the same domain change, user actions should become visible quickly, or integrations cannot be built as rigid call chains. It fits especially well in new solutions with clear event boundaries. Trade-off: more distributed components, harder tracing, and the need for well-defined events; existing monoliths are often expensive to retrofit.
Where this building block is located in the topic model.
Explore how this building block connects to concepts, methods, technologies, and tools.
These sources establish the term and its professional meaning.
All direct connections of the current building block in a compact text view.
This classification shows where the building block typically matters, how demanding it is, and what kind of impact it has in the model.
The level within the organization (enterprise, domain, team) at which the AssetBlock is applied.