cqrs-event-sourcing

CQRS and Event Sourcing

Overview

CQRS (Command Query Responsibility Segregation): use a different model to update information than the model you use to read it. The write side enforces invariants; the read side answers questions. They are separate concerns with separate optimization needs.

Event Sourcing: store the sequence of events (immutable facts) rather than current state. Current state is derived by replaying events. Events are past-tense facts: TaskAdded, StateUpdated, ContextChanged.

These are complementary but separate patterns. You can use CQRS without Event Sourcing, and vice versa. Event Sourcing makes the write side append-only but makes querying impractical without read models -- hence the natural pairing.

When to Use (and When NOT To)

CQRS adds value when:

• Read and write shapes differ significantly
• Multiple read models serve different consumers
• Read/write workloads have different scaling needs

Event Sourcing adds value when:

• Event history has intrinsic business value (audit, temporal queries)
• You need "what did this look like last Tuesday?"
• New read models must be buildable from existing data retroactively

Warning signs of over-application (per Greg Young):

• Event-sourcing simple CRUD with no complex invariants
• Events are just FieldChanged { old, new } instead of meaningful domain events
• Only one read model that mirrors the write model
• Optimizing for problems you don't have

Greg Young: "The single biggest bad thing I've seen is building an entire system on Event Sourcing." Apply selectively, per bounded context.

Core Concepts

Commands, Events, Queries

Concept	Direction	Purpose	Example
Command	Intent to change	Validated, may be rejected	MarkTaskDone { name }
Event	Fact that happened	Immutable, append-only	TaskCompleted { name, timestamp }
Query	Request for data	Never changes state	ListActiveTasks