cqrs-implementationlisted

# CQRS Implementation CQRS splits the model that **changes** state (commands → write model) from the model that **reads** state (queries → read model). Writes append events/state; one or more **projections** consume those events to build denormalized read models optimized per query. The two sides evolve and scale independently, at the cost of **eventual consistency** between them. ## Use this skill when - Read and write workloads differ enough that one model serves neither well. - Reads must scale independently from writes (read replicas, denormalized views). - Building event-sourced systems (CQRS is the natural read side of event sourcing). - Complex reporting / search views over the same data. ## Do not use this skill when - The domain is simple and plain CRUD is sufficient — CQRS adds real operational cost. - You require strong immediate consistency everywhere (read-your-writes on every path). - You cannot operate and monitor separate read/write stores plus projection lag. ## Core shape | Component | Responsibility | | --------------- | ------------------------------- | | Command | Intent to change state | | Command Handler | Validates and executes commands | | Event | Record of a state change (fact) | | Query | Request for data | | Query Handler | Reads from the read model | | Projector | Updates the read model from events | Commands go through a command bus to handlers that m