Event Sourcing and CQRS

Event Sourcing and CQRS

Implementation patterns for DDD. Event Sourcing stores every state change as an immutable event and derives current state from replay. CQRS separates write and read models. These are tools, not mandatory architecture -- apply selectively to domains where they add value.

When to Use Event Sourcing

ES adds value when:

• Complete audit trail required (financial, regulatory, medical)
• Temporal queries needed ("what was the state on January 15?")
• Multiple views of same data (different read models for different consumers)
• Complex domain with rich business rules (natural fit with DDD aggregates)
• Event-driven integration with other systems
• Debugging requires replay ("what exactly happened?")

ES is overkill when:

• Simple CRUD with no audit requirements
• Team unfamiliar and project has no learning budget
• No business value from history
• Domain has no behavior (data in, data out)

Key question: "Does knowing the history of how we got here provide business value?" Yes -> consider ES. No -> traditional CRUD is simpler.

Core Concepts

Events as Facts

Events are immutable records of things that happened. Past tense: OrderPlaced, PaymentReceived, ItemShipped.

Event structure: Include all data needed to understand what happened (self-contained) | Use domain language | One event per meaningful business fact | Events carry data only, no behavior

Granularity: Too coarse (OrderUpdated { order: {...} }) loses what changed. Too fine (OrderFieldChanged { field, old, new }) is generic audit log. Just right (OrderConfirmed { orderId, confirmedBy, confirmedAt }) has clear business meaning.

The Event Store

Single source of truth. Core operations:

• append(streamId, expectedVersion, events) -> success or concurrency conflict
• read(streamId) -> ordered list of events
• subscribe(filter) -> push notification for new events

Properties: Append-only (never modify/delete) | Ordered within stream | Immutable | Versioned (each event has position)