# Nw Ddd Eventsourcing

Event Sourcing and CQRS as DDD implementation patterns, when to use, aggregate event...

- Repository: https://github.com/nWave-ai/nWave (628 stars)
- Category: Engineering
- License: MIT
- Last updated: 2026-09-16
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add nWave-ai/nWave --skill nw-ddd-eventsourcing -g -a claude-code -y`
Codex: `npx skills add nWave-ai/nWave --skill nw-ddd-eventsourcing -g -a codex -y`
Cursor: `npx skills add nWave-ai/nWave --skill nw-ddd-eventsourcing -g -a cursor -y`
Gemini CLI: `npx skills add nWave-ai/nWave --skill nw-ddd-eventsourcing -g -a gemini-cli -y`
Claude Code plugin marketplace: `/plugin marketplace add nWave-ai/nWave`

## Description

Event Sourcing and CQRS as DDD implementation patterns, when to use, aggregate event streams, projections, snapshots, sagas, upcasting, conflict resolution

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# Event Sourcing and CQRS

Implementation patterns for DDD. Event Sourcing stores every state change as an immutable event and derives current state from replay. CQRS separates write and read models. These are tools, not mandatory architecture -- apply selectively to domains where they add value.

## When to Use Event Sourcing

**ES adds value when**:
- Complete audit trail required (financial, regulatory, medical)
- Temporal queries needed ("what was the state on January 15?")
- Multiple views of same data (different read models for different consumers)
- Complex domain with rich business rules (natural fit with DDD aggregates)
- Event-driven integration with other systems
- Debugging requires replay ("what exactly happened?")

**ES is overkill when**:
- Simple CRUD with no audit requirements
- Team unfamiliar and project has no learning budget
- No business value from history
- Domain has no behavior (data in, data out)

**Key question**: "Does knowing the history of how we got here provide business value?" Yes -> consider ES. No -> traditional CRUD is simpler.

## Core Concepts

### Events as Facts

Events are immutable records of things that happened. Past tense: `OrderPlaced`, `PaymentReceived`, `ItemShipped`.

**Event structure**: Include all data needed to understand what happened (self-contained) | Use domain language | One event per meaningful business fact | Events carry data only, no behavior

**Granularity**: Too coarse (`OrderUpdated { order: {...} }`) loses what changed. Too fine (`OrderFieldChanged { field, old, new }`) is generic audit log. Just right (`OrderConfirmed { orderId, confirmedBy, confirmedAt }`) has clear business meaning.

### The Event Store

Single source of truth. Core operations:
- `append(streamId, expectedVersion, events)` -> success or concurrency conflict
- `read(streamId)` -> ordered list of events
- `subscribe(filter)` -> push notification for new events

The rest: https://github.com/nWave-ai/nWave/blob/HEAD/nWave/skills/nw-ddd-eventsourcing/SKILL.md