nw-ddd-eventsourcing

# 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...