Domain Event

Origin & evolution

The term grew out of domain-driven design, where an event names a happening the domain experts care about. Martin Fowler catalogued the pattern alongside the rest of the event family on his site, distinguishing the domain event as a record of a significant occurrence within a model. The naming convention came with it: events are written in the past tense because they assert that something is already true.

Event sourcing pushed the idea further. Greg Young is generally credited with formalising the pattern, in which the stored sequence of events becomes the source of truth and current state is a fold over that history. Young's companion idea, Command Query Responsibility Segregation, separates the model that accepts changes from the model that answers questions. A command expresses intent and may be refused; an event reports a settled fact and cannot be argued with. That asymmetry is the whole point.

Fowler later warned, in his 2017 GOTO talk, that "event-driven" had become four overlapping patterns wearing one label: event notification, event-carried state transfer, event sourcing, and CQRS. The domain event sits underneath all four, which is why teams adopt it without realising which architecture they have signed up for.

How it works in practice

A payments service handles a customer paying for an order. The flow starts with a command, CapturePayment, which the service validates against the card and the order total. If it succeeds, the service does not return a status code and forget. It appends a PaymentCaptured event to its log, carrying the order ID, amount, and timestamp.

Downstream, three consumers react to that one fact. A read model🪟Read ModelEngineeringA DDD read model (query projection)View reference → for the customer dashboard🎛️DashboardData & AnalyticsAn analytics dashboardView reference → updates "paid" against the order. The fulfilment context treats the event as a trigger and issues its own command, ReserveStock. The finance context appends a ledger entry. None of them had to be named in the payment service; they subscribed to the event. Months later, a fraud team replays the entire PaymentCaptured stream through a new detection model, possible only because the events were stored as facts rather than thrown away after updating a row.

Domain event vs. its neighbours

• Command: a command is a request to change state, named as an imperative (CapturePayment), addressed to one handler, and allowed to fail. A domain event is the past-tense fact that results (PaymentCaptured), broadcast to anyone listening, and never rejected. The system flows command, then event, then possibly another command.
• Aggregate: an aggregate is the consistency boundary that decides whether a change is valid and then emits the event recording it. The event is the aggregate's public account of what it did.
• Read model: a read model is a view built by projecting events into a shape optimised for queries. The event is the raw fact; the read model is one interpretation of many facts, and it can be rebuilt by replaying the stream.

In the graph

In the Unified Product Graph, a domain event sits in the engineering region as the connective tissue of an event-driven system. It is emitted by the structures that own state (bounded_context_emits_domain_eventBounded ContextemitsDomain Eventhierarchy, aggregate_emits_domain_eventAggregateemitsDomain Eventcausal) and produced as the consequence of intent (command_produces_domain_eventCommandproducesDomain Eventcausal). From there it fans out: it feeds query-side views (domain_event_projected_to_read_modelDomain Eventprojected toRead Modelcausal) and can set off further work (domain_event_triggers_commandDomain EventtriggersCommandcausal). Modelling the event as a first-class node, with both its causes and its effects as edges, makes the otherwise invisible choreography of an event system legible: you can trace which command produced a fact and every consumer that woke up because of it.