What this prompt does
This prompt implements CQRS with Event Sourcing for a [domain] system on Spring Boot [spring_version]. It defines a command model with an aggregate root for [aggregate] rebuilt from events, an event store on [event_store_backend], command and event handlers, read models optimized for [read_queries] using [read_db], eventual-consistency handling, a snapshot strategy at [snapshot_frequency], event versioning, a saga for [saga_flow], and integration tests proving the command-to-event-to-projection flow.
The structure works because CQRS and event sourcing are frequently adopted for the wrong reasons and then collapse under production realities. By forcing the projection-lag, event-versioning, and snapshot sections, the prompt confronts the parts that actually decide whether event sourcing survives: replaying years of events, evolving event schemas without breaking replay, and keeping read models consistent. Naming [aggregate] and [saga_flow] grounds the design in a concrete domain instead of abstract theory.
When to use it
- When a
[domain]genuinely needs a full audit trail of every state change - When read and write workloads differ enough to justify separate models
- When you must replay history to rebuild or correct read models
- When a cross-aggregate workflow like
[saga_flow]needs coordinated steps - When event schemas will evolve and replay must keep working across versions
- When you are weighing event sourcing and need an honest view of its costs
- When aggregates accumulate enough events that you need a snapshot strategy to keep rebuilds fast
Example output
Expect a Spring Boot design: the [aggregate] command model rebuilt from events, the append-only event store on [event_store_backend], command handlers enforcing business rules, event handlers projecting into read models, the [read_db] projection optimized for [read_queries], a snapshot strategy at [snapshot_frequency], an event-versioning approach that survives schema changes, the [saga_flow] saga with compensating steps, and integration tests verifying the command-to-event-to-projection flow. It typically includes an architecture diagram description and notes on handling projection lag rather than only code fragments, so the trade-offs of eventual consistency are visible before you commit to the pattern.
Pro tips
- Be sure the
[domain]truly needs event sourcing; if you do not need an audit trail or replay, plain CRUD is simpler and the prompt's honesty about that is worth heeding - Tune
[snapshot_frequency]to your aggregate's event volume — too rare and rebuilds get slow, too frequent and you store redundant state - Treat event versioning as mandatory; schema changes that break replay are the most common way event-sourced systems fail in production
- Define
[saga_flow]steps with compensating actions so a partial failure can be rolled back cleanly - Plan for projection lag explicitly; read models are eventually consistent, so the UI must tolerate brief staleness
- Decide
[cqrs_framework]deliberately — Axon brings a lot, but a custom implementation may be clearer for a focused domain
