关于 cqrs
这是一份 CQRS 参考技能，说明何时分离写入与读取模型、架构如何运作及其权衡，帮助开发者评估是否采用并避开常见设计问题。
主要功能
- 01CQRS 适用时机指南
- 02命令与查询模型概览
- 03权衡与一致性考量
- 04相关模式与反模式
适用场景
- 01评估复杂业务领域是否适合 CQRS
- 02规划读写独立扩展
- 03审视事件驱动架构选择
- 04识别 CQRS 设计问题
安装
复制下面的命令，在终端中运行。
$
npx skills add https:/安装后在 Claude Code 中输入/cqrs确认已加载。
附带文件REFERENCE.md
详细介绍
CQRS — 快速参考
CQRS（命令查询职责分离）将写入和读取操作分离到不同的模型中。并非默认采用的方案——只有在复杂性成本合理时，才应将其作为优化启用。
何时使用
| 适用 | 不适用 |
|---|---|
| 业务领域复杂，不变量规则丰富 | 简单 CRUD，贫乏领域 |
| 读写比 > 10× | 小型项目、初级团队 |
| 审计 / 合规（天然适合 Event Sourcing） | 要求即时一致性 |
| 多种异构读取模型（移动端 vs 分析 vs 后台管理） | 稳定且唯一的数据模型 |
| 读写分别扩展（副本、缓存、搜索） | 负载低、规模适中的单体应用 |
黄金法则： 从经典架构开始。当至少 2 个适用场景同时出现时，再迁移到 CQRS。
30 秒了解架构
[ User ]
↓
[ Command ]──────────▶ [ Write Model (Domain) ]
↓ persist + emit
[ Event(s) ]
↓
[ Query ] ◀───── [ Read Model (denormalised) ] ◀── projections
- 命令端：采用规范化模型，聚焦业务不变量。负责写入，只读取验证所需的数据。
- 查询端：采用反规范化模型，聚焦读取性能。不包含业务逻辑。
- 投影：将事件转换为读取模型。最终一致。
核心权衡
| 优势 | 成本 |
|---|---|
| 读写可独立扩展 | 最终一致性（典型延迟约为 50-500 ms） |
| 读取模型可针对各类需求定制 | 需要维护更多代码（2 个模型） |
| 易于接入 Event Sourcing | 调试更复杂（事件流） |
| 天然具备审计跟踪 | 后期迁移成本极高 |
相关模式（常常搭配使用）
- Event Sourcing：将事件序列存储为事实来源，通过重放重建写入模型。
- Saga / Process Manager：通过事件编排分布式事务。
- Outbox Pattern：确保事件发布与数据库写入的原子性。
- Materialized Views：将投影持久化到专用表中，以提升查询速度。
关键反模式
- ❌ 没有明确用例就采用 CQRS → 过度设计，增加双倍认知负担。
- ❌ 读取模型执行业务规则 → 每次投影都会导致不变量错误。
- ❌ 同步投影 → 失去可扩展性的优势。
- ❌ 不使用快照的 Event Sourcing → 启动时重放数百万个事件。
- ❌ 返回完整数据的命令 → 这是伪装成命令的查询。
深入了解
Symfony / Laravel / .NET 实现、Event Sourcing（Prooph、EventStoreDB）、Saga 模式、Outbox、具体示例、从 CRUD 渐进式迁移到 CQRS、各阶段检查清单：参见
@.claude/skills/cqrs/REFERENCE.md。
评论
支持 Markdown