golang-ddd-cqrs

Golang DDD CQRS

使用此技能将应用逻辑拆分为清晰的命令和查询，避免让 Go 代码变成充斥着繁琐仪式的企业级脚手架。

从这里开始

• 当服务具有重要的写入端行为、读写模型混杂，或应用服务难以理解时，使用 CQRS。
• 如果服务大多是简单的 CRUD 或类似登录的流程，业务行为很少，则跳过或尽量少用 CQRS。

工作流

1. 将用例拆分为写入和读取。

• 命令会修改状态，并可能返回错误。
• 查询返回数据，不应执行业务变更。

2. 使用业务语言命名。

• 优先使用 ScheduleTraining、CancelTraining、ApproveReschedule、AvailableHours。
• 除非业务确实使用这类名称，否则避免使用默认的 CRUD 名称。

3. 在有助于提升清晰度时，引入独立的处理器。

• 如果逻辑或依赖项不同，则为每条命令使用一个命令处理器类型。
• 如果读取关注点不同，则为每条查询使用一个查询处理器类型。
• 保持接口精简，并由使用它的处理器负责。

4. 让处理器只负责协调。

• 领域规则属于领域层。
• 传输映射属于端口。
• 数据库或外部 API 细节属于适配器。

5. 围绕 CQRS 设计端口。

• HTTP 或 gRPC 端口可以直接调用命令。
• 如果创建命令需要后续读取，在实际可行时，优先返回 204 No Content 和 content-location，或者在命令之后显式执行查询。
• 在边界处处理端口特有的错误转换。

6. 将应用层作为协调层进行测试。

• 使用小型手写模拟对象来模拟仓储和出站服务。
• 除非行为确实属于应用协调，否则应在领域测试中断言业务场景。

注意事项

• 如果服务仍然很简单，不要创建独立的命令和查询包。
• 默认情况下，不要让命令返回大型读取模型。
• 不要仅仅因为命令处理器用起来方便，就把业务逻辑藏在其中。
• 如果拆分处理器可以精简接口和测试，就不要保留一个庞大的应用服务。

使用以下参考资料

• 阅读 references/cqrs-guidelines.md，了解命名、打包方式和权衡。
• 阅读 references/application-tests-and-errors.md，了解处理器测试和与传输无关的错误。

交付内容

• 与用例相匹配的命令和查询边界，
• 面向业务的名称，
• 由处理器负责的精简接口，
• 精简的传输代码，
• 聚焦于协调而非领域内部细节的处理器测试。