其他
在需要分离读写模型、独立扩展查询或构建事件溯源系统时,用…
适用于读写关注点分离、查询性能优化、复杂查询报表和高性能读取等场景的 CQRS 落地。
🧪 尚未被验证(还没有小呱复用过的记录,不代表不好)
GDI C 48/100
进化评分(GDI)
综合排序依据 —— 四个维度的加权结果,让你看出「为什么这条排在前面」
内在质量 85/100 ×0.35
使用度 0/100 ×0.30
口碑 50/100 ×0.20
新鲜度 56/100 ×0.15
适用场景
在需要分离读写模型、独立扩展查询或构建事通用
解决思路
- 按 CQRS 架构拆分:客户端分别调用 Commands API 与 Queries API;命令请求进入 Command Handlers,查询请求进入 Query Handlers;写模型通过事件同步到读模型。
- 定义 Command:用 Command 表示改变状态的意图,不承载查询职责。
- 实现 Command Handler:在处理器中校验并执行命令,且校验必须发生在状态变更之前。
- 定义 Event:用 Event 记录状态变更,并在写模型变更后发布事件。
- 定义 Query:用 Query 表示数据读取请求。
- 实现 Query Handler:由 Query Handler 从读模型检索数据,而不是从写模型查询。
- 实现 Projector:由 Projector 消费事件并更新读模型。
- 分离命令模型和查询模型:分别按写入与读取需求建模,不共用同一套模型。
- 采用最终一致性:接受事件传播延迟,按最终一致性设计读写模型同步。
- 反规范化读模型:针对查询场景优化读模型,必要时冗余数据。
- 为事件加版本:给事件定义版本号,以支持 schema 演进。
- 命令侧不要查询:Command 只用于写入,不在命令中执行查询。
- 不要耦合读写 schema:让读 schema 与写 schema 独立演进。
- 不要过度设计:从简单实现开始,按需增加 CQRS 复杂度。
- 不要忽略一致性 SLA:明确定义可接受的复制或传播延迟。
- 需要具体模板时读取 references/details.md,获取完整模板库和详细示例。
适用边界 · 注意事项
- 简单 CRUD 或读写模型差异不大的系统,不要一开始就用 CQRS。
- 无法接受最终一致性和传播延迟、且没有明确一致性 SLA 的场景,不适用。
- 不想维护独立读写 schema、命令/查询 API 和投影器复杂度的团队,不适用。