Should a domain event's payload carry the full state of the aggregate at the time it was raised, or just the minimal data needed to describe what changed, like IDs and the specific delta? What are the trade-offs?

## The decision, in one line The payload-shape decision comes down to how much a domain event should be a **self-contained snapshot** versus a **minimal, narrow signal** that something happened, and it has real consequences for coupling, staleness, and correctness that only show up once a system has more than one or two listeners. | | Thin event | Fat event | |---|---|---| | Payload | typically the aggregate's identifier, an occurred-at timestamp, and whatever fields are specific to that particular event | a broader snapshot embedded directly in the payload | ## The thin event A thin event carries the smallest set of data that lets a listener understand the fact and act on it: typically the aggregate's identifier, an occurred-at timestamp, and whatever fields are specific to that particular event — `OrderShipped` might carry `{orderId, trackingNumber, shippedAt}` and nothing else about the order. If a listener needs more, say the customer's email to send a shipping notification, it looks the `Order` or `Customer` back up via a repository at the time it handles the event, getting current state as of that moment. This keeps the event's shape stable and small: adding a new field to the `Order` aggregate doesn't require touching the `OrderShipped` event unless that field is relevant to shipping specifically, and the event can't leak data a listener wasn't supposed to see, because it was never included. ## The fat event, and what it costs A fat event instead embeds a broader snapshot directly in the payload, so a listener can act without any further lookup. This is attractive across a process or context boundary where a lookup means a network call, and is common practice at the integration-event layer, deliberately out of scope for the pure in-process domain-event decision here, where avoiding chatty cross-service calls matters a lot. Inside the domain model itself, though, a fat event has real costs. 1. **First, coupling:** every field included is now part of the event's contract, so any consumer relying on it makes that field harder to remove or rename later — the event's payload becomes a second, informally-versioned copy of the aggregate's shape that has to be kept in sync by hand. 2. **Second, staleness:** if a listener processes the event some time after it was raised — queued, retried, scheduled slightly later — the snapshot inside the event reflects the aggregate's state at the moment it was raised, not at the moment the listener runs; if the aggregate changed again in between, a listener that trusts the embedded snapshot instead of re-fetching can act on stale data without realizing it, whereas a thin event forcing a fresh lookup naturally avoids this. 3. **Third, over-exposure:** a fat snapshot handed to every listener means listeners that only care about one fact also receive fields they have no business seeing, both a minor privacy smell and something that makes it harder to reason about who depends on what. ## The failure mode that actually bites The failure mode that shows up most often in practice with fat events is exactly the staleness issue: a listener queued behind a slow downstream call processes an `OrderUpdated{full order snapshot}` event twenty seconds after it was raised, unaware that a second `OrderUpdated` event was raised and already processed by a faster listener in the meantime — if the slow listener naively writes its snapshot's values into a read-model or cache, it can overwrite newer data with older data, a classic out-of-order-update bug. Thin events don't eliminate this risk entirely, since ordering still matters for the delta itself, but they at least prevent a listener from confidently overwriting broad swaths of state based on a stale full snapshot; a listener working from a thin event and a fresh lookup only overwrites what it re-reads as current. ## Where many DDD codebases land A concrete, well-known resolution: many DDD codebases keep in-model domain events thin and intent-specific (`OrderShipped`, `PaymentCaptured`, each with a handful of directly relevant fields), and only build a fatter, versioned payload when translating a domain event into an outbound integration event at a bounded-context boundary — at which point the fatness is a deliberate contract decision made with API-versioning discipline, not an accidental byproduct of convenience inside the domain model itself.