home / skills / partme-ai / full-stack-skills / ddd-event-driven

ddd-event-driven skill

This skill provides guidance on event-driven architecture, including domain events, event sourcing, and CQRS, to design scalable systems.

npx playbooks add skill partme-ai/full-stack-skills --skill ddd-event-driven

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

Files (2)

SKILL.md

672 B

---
name: ddd-event-driven
description: Provides comprehensive guidance for event-driven architecture including domain events, event sourcing, CQRS, and event patterns. Use when the user asks about event-driven architecture, needs to implement event-driven systems, or work with domain events.
license: Complete terms in LICENSE.txt
---

## When to use this skill

Use this skill whenever the user wants to:
- [待完善：根据具体工具添加使用场景]

## How to use this skill

[待完善：根据具体工具添加使用指南]

## Best Practices

[待完善：根据具体工具添加最佳实践]

## Keywords

[待完善：根据具体工具添加关键词]

Overview

This skill provides practical, hands-on guidance for designing and implementing event-driven architectures using Domain-Driven Design (DDD) patterns. It covers domain events, event sourcing, CQRS, common event patterns, and pragmatic integration strategies for production systems. The content emphasizes concrete decisions, trade-offs, and implementation steps in Python-centered stacks.

How this skill works

The skill inspects architectural goals, domain boundaries, and existing data flows to recommend event models, consistency strategies, and storage choices. It explains how to capture domain events, model event streams, apply event sourcing, and separate read/write concerns with CQRS. It also advises on messaging infrastructure, idempotency, schema evolution, and operational concerns like monitoring and replay.

When to use it

Designing a system that must scale with asynchronous business processes and loose coupling
Migrating a monolith to microservices while keeping strong domain semantics
Implementing auditability, temporal queries, or rebuildable state with event sourcing
Separating read models for high-performance queries using CQRS
Defining integration between bounded contexts or external systems via domain events

Best practices

Model events as immutable, explicit domain facts with versioned schemas
Keep event payloads lean; include identifiers and essential state needed for consumers
Prefer eventual consistency and design compensating actions rather than forcing sync calls
Use idempotency keys and deduplication for consumer resilience
Plan for schema evolution (versioning, upcasters) and retention/replay strategies

Example use cases

Order processing: emit OrderPlaced, OrderPaid, OrderShipped events to decouple fulfillment and billing
Inventory: use event sourcing to reconstruct stock levels and support audit trails
User activity tracking: publish events for analytics consumers without impacting transactional flows
Payment reconciliation: build read models for reporting while writing transactions via CQRS
Cross-service integration: use domain events as the canonical integration contract between bounded contexts

FAQ

When should I use event sourcing instead of a traditional relational model?

Use event sourcing when you need an authoritative audit log, the ability to rebuild state, or when domain behavior is naturally expressed as a sequence of events. Avoid it for simple CRUD domains where added complexity outweighs benefits.

How do I handle breaking changes to event schemas?

Version events and provide upcasters or migration tools. Maintain backward compatibility by keeping old event handlers or transforming events at read/write boundaries.