home / skills / nickcrew / claude-cortex / cqrs-event-sourcing

cqrs-event-sourcing skill

/skills/cqrs-event-sourcing

This skill helps you implement CQRS and Event Sourcing to build auditable, scalable systems with clear read/write boundaries.

npx playbooks add skill nickcrew/claude-cortex --skill cqrs-event-sourcing

Review the files below or copy the command above to add this skill to your agents.

Files (6)
SKILL.md
3.8 KB
---
name: cqrs-event-sourcing
description: CQRS and Event Sourcing patterns for scalable, auditable systems with separated read/write models. Use when building audit-required systems, implementing temporal queries, or designing high-scale applications with complex domain logic.
---

# 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 = '[email protected]'`
**Event Sourcing**: Store what HAPPENED → `APPEND UserEmailChanged event`

**Result**: Complete history, temporal queries, audit trail

### 3. Eventual Consistency
Accept temporary inconsistency between write and read models for scalability.

### 4. Domain-Driven Design Integration
- Aggregates enforce business invariants
- Events represent domain facts
- Commands express domain operations
- Bounded contexts define consistency boundaries

## Quick Reference

| Task | Load reference |
| --- | --- |
| CQRS implementation patterns | `skills/cqrs-event-sourcing/references/cqrs-patterns.md` |
| Event sourcing & snapshots | `skills/cqrs-event-sourcing/references/event-sourcing.md` |
| EventStoreDB & Axon Framework | `skills/cqrs-event-sourcing/references/event-store-tech.md` |
| Consistency patterns | `skills/cqrs-event-sourcing/references/consistency-patterns.md` |
| Best practices checklist | `skills/cqrs-event-sourcing/references/best-practices.md` |

## Workflow

1. **Identify** if CQRS/ES is appropriate (high audit, temporal, or scale needs)
2. **Design** commands expressing user intent
3. **Define** events as immutable facts (past tense naming)
4. **Implement** aggregates as consistency boundaries
5. **Create** projections optimized for specific query needs
6. **Handle** eventual consistency across bounded contexts

## Common Mistakes

- Using CQRS for simple CRUD applications (overkill)
- Large aggregates that span multiple consistency boundaries
- Modifying or deleting events after publication
- Skipping command validation before aggregate processing
- Missing idempotency in event handlers
- No versioning strategy for event schema evolution
- Tight coupling between aggregates (use ID references only)

## Resources

- **Books**: "Implementing Domain-Driven Design" (Vernon), "Event Sourcing & CQRS" (Betts et al)
- **Sites**: cqrs.wordpress.com, eventstore.com/blog, axoniq.io/resources
- **Tools**: EventStoreDB, Axon Framework, Marten, Eventuous
- **Patterns**: Event Sourcing, CQRS, Process Manager, Saga, Snapshot

Overview

This skill provides practical guidance and patterns for implementing CQRS (Command Query Responsibility Segregation) and Event Sourcing to build scalable, auditable systems with separated read/write models. It focuses on designing commands, immutable events, aggregates, and projections so systems can support temporal queries, complete audit trails, and high-scale domain logic. The content is Python-focused and suited for engineers building enterprise or collaboration platforms.

How this skill works

The skill explains how to model intent as commands, record every change as immutable events, and use aggregates to enforce business invariants. It describes creating read-model projections optimized for queries and managing eventual consistency between write and read sides. Practical guidance covers snapshots, idempotent handlers, event versioning, and tools commonly used in Python ecosystems and event stores.

When to use it

  • When you need a full audit trail and the ability to replay history
  • To support temporal queries like “show state at time T”
  • When read and write access patterns diverge significantly
  • For high-scale domains with complex business invariants
  • When building event-driven architectures or multi-projection systems

Best practices

  • Model commands for intent and events in past-tense to represent facts
  • Keep aggregates bounded and focused to avoid cross-boundary consistency issues
  • Make event handlers idempotent and add versioning for schema evolution
  • Use snapshots to limit event replay cost for long-lived aggregates
  • Accept eventual consistency and design user UX to surface that state

Example use cases

  • Financial or compliance systems requiring immutable audit logs and replay
  • E-commerce order processing with separate read views for product catalogs and dashboards
  • Collaboration platforms where conflict resolution and history tracking matter
  • Recommendation engines that rebuild projections from event streams
  • Microservice ecosystems that use events for integration and sagas

FAQ

Is CQRS and Event Sourcing appropriate for every application?

No. It adds complexity and is best for systems needing auditability, temporal queries, or distinct read/write scaling. Avoid for simple CRUD apps.

How do I handle schema changes to events?

Use explicit versioning, backward-compatible transformations, and migration handlers or adapters during replay. Keep evolution predictable and documented.