Every architecture covered so far — layered, onion, hexagonal, clean — shares a synchronous, request-response mental model: a caller invokes a function, waits for a result, and proceeds. Event-Driven Architecture (EDA) is a fundamentally different paradigm. Components communicate by producing and consuming events — records of something that happened. The producer does not know who will consume the event, or when. This temporal decoupling unlocks a class of system properties — scalability, resilience, loose coupling — that synchronous architectures struggle to achieve. It also introduces a new class of problems that synchronous architectures avoid by design.
ℹ️An event is an immutable record of a fact that already happened: 'OrderPlaced', 'PaymentProcessed', 'InventoryReserved'. Events are named in the past tense because they describe history, not intent. This is the key distinction from a command ('PlaceOrder'), which expresses intent and expects a result.
Content is available with subscription.
Get full access to all courses on the platform for one year with a single payment.
▼
Unlike other platforms that charge per course, here you get everything for one price, and after one year of use there will be no automatic charge for the following year.