golang-ddd-architecture

Golang DDD 架构

使用此技能来构建 Go 服务，使其随着业务逻辑增长，仍然易于修改、测试和理解。

从这里开始

• 判断服务是否足够复杂，值得采用此模式。
• 对于简单的 CRUD 或身份验证流程，如果读写数据结构大体相同且业务规则较少，就采用更精简的设计。
• 如果处理器中的 if 分支不断增多、模型在不同边界间复用，或依赖难以模拟或理清，就使用完整工作流。

工作流

1. 梳理入口点和用例。

• 从 HTTP 处理器、gRPC 服务、CLI 命令、消息消费者和定时任务入手。
• 在调整代码之前，先用业务语言重新描述支持的操作。

2. 绘制边界图。

• ports 仅负责入站传输和序列化。
• app 编排用例。
• domain 负责业务规则和不变量。
• adapters 与数据库、队列、外部 API、文件及其他基础设施交互。

3. 强制依赖方向。

• domain 不依赖自身以外的任何内容。
• app 可以导入 domain，但不能导入具体的传输层或适配器包。
• ports 和 adapters 可以导入内层。
• 通过将接口移入内层或拆分职责来解决导入循环，而不是把所有内容都压平到一个包中。

4. 将接口放在使用方旁边。

• 在需要该行为的包中定义接口。
• 接口应保持精简，并面向用例。
• 从组合根注入实现。

5. 分离因不同原因而变化的模型。

• 除非数据库行、API 响应、Pub/Sub 负载和领域状态的变化节奏确实相同，否则不要用同一个结构体表示它们。
• 如果数据重复能减少耦合，就接受这种重复。DRY 通常更适用于行为，而非数据。

6. 让 main 保持简单。

• 将 main 用作组合根。
• 在其中装配存储库、客户端、处理器和配置。
• 不要在其中隐藏业务逻辑、验证或工作流分支。

7. 让代码库比接手时更易于测试。

• 领域规则应可在不使用 mock 的情况下进行单元测试。
• 应用编排应可通过简单的手写 mock 进行测试。
• 适配器行为应通过集成测试覆盖。

使用这些参考资料

• 阅读 references/architecture-rules.md，了解分层规则、包布局和反模式。
• 在命名、模型边界或共享结构体的权衡难以处理时，阅读 references/naming-and-models.md。

交付内容

• 清晰的分层图或包规划；
• 无需通过导入循环变通方案即可编译的依赖方向；
• 组合根中的构造函数或装配点；
• 明确的模型边界；
• 如果系统过于纠缠，无法一次性完成改造，则提供一份简短的后续重构待办清单。