cqrs-event-sourcinglisted

# CQRS and Event Sourcing Patterns Expert guidance for implementing Command Query Responsibility Segregation (CQRS) and Event Sourcing patterns to build scalable, auditable systems with complete historical tracking and optimized read/write models. ## When to Use This Skill - Building systems requiring complete audit trails and compliance - Implementing temporal queries ("show me the state at time T") - Designing high-scale applications with complex domain logic - Creating systems with significantly different read and write patterns - Building event-driven architectures with historical replay capability - Implementing systems requiring multiple read model projections - Designing applications where understanding "what happened" is critical - Building collaborative systems with conflict resolution needs ## Core Principles ### 1. Command Query Separation Separate operations that change state (commands) from operations that read state (queries). | Commands (Write) | Queries (Read) | |-----------------|----------------| | Express intent (CreateOrder, UpdatePrice) | Return data, never change state | | Can be rejected (validation failures) | Can be cached and optimized | | Return success/failure, not data | Multiple models for different needs | | Change system state | Eventually consistent with writes | ### 2. Events as Source of Truth Store state changes as immutable events rather than current state snapshots. **Traditional**: Store what IS → `UPDATE users SET email = 'new@e