用途：在 Go 服务中建立或重构 DDD 风格架构，让业务逻辑增长后仍易于修改、测试和理解。先判断服务是否复杂到需要该模式：简单 CRUD 或认证流程、读写结构基本一致且业务规则单薄时，应保持更小的设计；当 handler 中 if 树不断膨胀、模型跨边界复用、依赖难以 mock 或理清时，再使用完整流程。
主要能力与工作流：一，盘点入口与用例，从 HTTP handler、gRPC 服务、CLI 命令、消息消费者和定时任务出发，先用业务语言重写支持的操作。二，绘制边界图：ports 只负责入站传输与序列化，app 编排用例，domain 拥有业务规则与不变量，adapters 对接数据库、队列、外部 API、文件等基础设施。三，强制依赖方向：domain 不依赖自身之外的任何东西；app 可导入 domain，但不能导入具体传输或适配器包；ports 与 adapters 可向内层导入。修复导入环时应把接口内移或拆分职责，而不是把所有东西压平到一个包。四，接口放在消费者旁边，在需要该行为的包中定义，保持窄小且面向用例，由组合根注入实现。五，分离因不同原因变化的模型，不要用同一个 struct 同时承载数据库行、API 响应、Pub/Sub 载荷和领域状态，除非变化节奏确实相同；为解耦可接受数据重复，DRY 对行为通常比数据更有价值。六，保持 main 简单，作为组合根装配仓库、客户端、handler 和配置，不隐藏业务逻辑、校验或流程分支。七，提升可测试性：领域规则无需 mock 即可单元测试，应用编排可用手写小 mock 测试，适配器行为用集成测试覆盖。
参考与交付：可阅读 references/architecture-rules.md 了解分层规则、包布局与反模式；命名、模型边界或共享 struct 取舍困难时阅读 references/naming-and-models.md。交付物包括清晰的层图或包计划、无导入环 hack 即可编译的依赖方向、组合根中的构造函数或装配点、明确的模型边界，以及系统过于混乱无法一次完成时的后续重构清单。限制：资料未提供具体安装命令、收费方式或平台支持信息。