用途：在 Go 项目中以务实方式引入 CQRS，把应用逻辑拆成清晰的命令（写）与查询（读），避免变成仪式感过重的企业级脚手架。当服务有实质写侧行为、读写模型混杂，或应用服务难以推理时使用；若服务基本是简单 CRUD 或类似登录的流程，业务行为很少，则应跳过或最小化 CQRS。
主要能力与工作流：把用例拆分为写与读；命令改变状态并可返回错误，查询返回数据且不应执行业务性变更。用业务语言命名，例如 ScheduleTraining、CancelTraining、ApproveReschedule、AvailableHours，避免默认 CRUD 命名，除非业务确实如此表达。在能提升清晰度时引入独立处理器：逻辑或依赖不同时，每个命令一个命令处理器类型；读关注点不同时，每个查询一个查询处理器类型。接口保持窄小，并由消费它的处理器拥有。处理器只做编排：领域规则属于领域层，传输映射属于端口，数据库或外部 API 细节属于适配器。端口围绕 CQRS 设计：HTTP 或 gRPC 端口可直接调用命令；若创建命令需要后续读取，实践中优先 204 No Content 加 content-location，或在命令后执行显式查询；端口特定的错误转换留在边缘。应用层按编排测试：用手写的小型 mock 模拟仓储与出站服务；业务场景断言留在领域测试中，除非该行为确实属于应用编排。
护栏：服务仍很简单时不要拆出独立的命令与查询包；命令默认不要返回大型读模型；不要因为方便就把业务逻辑藏进命令处理器；若拆分处理器能缩小接口与测试，就不要保留一个巨大的应用服务。
参考与交付：可阅读 references/cqrs-guidelines.md 了解命名、打包与权衡，阅读 references/application-tests-and-errors.md 了解处理器测试与传输无关错误。交付物包括：与用例匹配的命令与查询边界、面向业务的命名、处理器拥有的窄接口、薄传输代码，以及聚焦编排而非领域内部细节的处理器测试。