基础 CQRS（无事件溯源）
使用场景: 在不完全采用事件溯源的前提下尝试 CQRS 的团队
写模型：带规范化表的关系数据库
读模型：同一存储或不同存储中的去规范化视图
每条命令后发出事件供跨侧同步
可从写模型重建读模型
比事件溯源复杂度低，仍享受拆分带来的收益
这样组织的原因: 基础 CQRS 是最干净的入口——图表两侧都是普通数据库，事件桥接它们。你能获得独立扩展和读优化，同时不必承担事件溯源的复杂度。
真实案例
带事件溯源的 CQRS
使用场景: 希望事件日志成为真相来源的团队
写模型即事件存储本身——仅追加事件
通过重放事件派生状态
读模型通过订阅时投影事件构建
新读模型可从事件 0 重放添加
审计和时间旅行天然就有
这样组织的原因: CQRS + 事件溯源是最强形态——图表让事件存储成为系统记录，读模型从中完全派生。新增视图就是写一个新投影器。
多读模型
使用场景: 有多种不同查询模式的团队
一个写模型、多个专用读模型
Read 1：Elasticsearch 做全文搜索
Read 2：Redis 做低延迟查找
Read 3：Postgres 做复杂报表 JOIN
每个投影器独立消费同一事件流
这样组织的原因: 多读模型是 CQRS 最有力的依据——图表展示同一写侧喂多个投影，每个为不同访问模式优化，这是单一 CRUD 模型无法高效做到的。
微服务中的 CQRS
使用场景: 把 CQRS 作为按服务模式使用的团队
每个微服务按需选择 CQRS 或 CRUD
跨服务事件流过共享总线
服务 A 的事件喂服务 B 的读模型
Saga 模式协调跨服务写
API 网关对客户端隐藏拆分
这样组织的原因: CQRS 与微服务天然契合——图表展示按服务而非整系统使用，让每个服务只在能赢的地方采用 CQRS，跨服务事件处理协调。
使用技巧
- 始终把命令侧和查询侧画成独立 frame；合并就违背了模式的初衷。
- 把事件总线作为独立节点——它是最终一致性所在的接缝。
- 把投影器作为独立组件画出，而非读模型的属性；投影是可部署、可扩展的服务。
- 标注一致性边界，让评审者知道读可滞后于写；这是 CQRS 的特性，不是 bug。
在线开始编辑
回到模板页，直接替换成你的课程主题、章节和复习重点，就可以继续使用这套结构。
使用这个模板： /editor/new?template=cqrs-architecture
编辑此 CQRS 模板