From software-design
Use when CQRS changes aggregate boundaries or state shape. Helps reduce oversized command aggregates by moving read concerns to read models, keeping only command-decision state in aggregates, and using events for state transitions. Trigger for large aggregates, heavy command updates, aggregates containing query-only data, or boundary redesign during CQRS adoption.
How this skill is triggered — by the user, by Claude, or both
Slash command
/software-design:j5ik2o-cqrs-aggregate-modelingThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
In CQRS, an aggregate is not a read model. It only needs the state required to decide whether a command is valid and which events to emit.
In CQRS, an aggregate is not a read model. It only needs the state required to decide whether a command is valid and which events to emit.
Identify each command the aggregate handles.
List the state needed to validate and execute those commands.
Remove query-only projections, history lists, counters, denormalized display fields, and report data from the command aggregate.
Put read concerns into read models updated from events.
Redraw aggregate boundaries around true invariants and command contention.
Keep state minimal, invariant-bearing, and command-oriented.
Prefer IDs and event references over embedded external aggregates.
Model lifecycle as explicit state transitions when commands depend on it.
Treat unbounded collections as read-model material unless they enforce a true invariant.
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.
Return the command-state matrix, proposed aggregate boundary, events, read models, and migration risks.
Guides 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.
npx claudepluginhub j5ik2o/ai-tools --plugin software-design