From software-design
Use when explaining why CQRS often needs event sourcing or durable events for reliable command-to-query synchronization. Covers calculated value sync, database trigger limits, polling scalability, double commits, and making events the source of truth. Trigger for CQRS synchronization, read-model update strategy, CQRS without ES, or double-commit concerns.
How this skill is triggered — by the user, by Claude, or both
Slash command
/software-design:j5ik2o-cqrs-to-event-sourcingThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
CQRS separates command decisions from query views. The hard part is not the split; it is reliable synchronization from writes to reads.
CQRS separates command decisions from query views. The hard part is not the split; it is reliable synchronization from writes to reads.
Commands change business facts, not just tables.
Read models need derived state that often cannot be reconstructed safely from row triggers alone.
Polling creates latency, missed intent, ordering ambiguity, and scaling pressure.
Updating the write store and read store in one use case creates a double-commit problem.
Durable domain events solve this by recording what happened once and projecting it many times.
CQRS can be partial; non-CQRS areas can keep a unified model.
A small system can use transactional outbox events without full event-sourced aggregates.
Event sourcing is justified when history, replay, auditability, or projection repair matter.
For non-trivial implementation, review, or refactoring work, read references/details.md before giving final guidance. It contains the detailed rules, examples, smells, and migration notes that do not belong in the short invocation body.
Explain the synchronization failure mode first, then recommend event sourcing, outbox-based events, or a simpler approach based on scale and risk.
npx claudepluginhub j5ik2o/ai-tools --plugin software-designGuides collaborative design exploration before implementation: explores context, asks clarifying questions, proposes approaches, and writes a design doc for user approval.
Creates structured, bite-sized implementation plans from specs or requirements before writing code. Useful for breaking down multi-step tasks into testable steps with file structure and task boundaries.
Synthesizes the current conversation into a structured spec (PRD) and publishes it to the project issue tracker with a ready-for-agent label, without interviewing the user.