ddd-hexagonal-architecture（六边形架构技能）Skill：把端口与适配器、领域隔离与依赖反转讲清楚、落到位
- 一句话定位：这是一个专注「六边形架构（端口与适配器）」的 AI 技能，当你询问六边形架构、想实现端口与适配器模式、或用六边形架构搭建应用时，它会给出成体系的指导。
- 核心能力：覆盖端口与适配器的划分、领域层隔离、依赖反转三大关键点，帮你在写代码之前先把边界想明白。
- 使用门槛低：属于「提问即触发」型技能，不需要额外配置框架或模板，装好之后用自然语言提问即可。
- 适合谁用：后端工程师、架构师、技术负责人，以及正在做遗留系统改造、需要把业务逻辑从框架里「拔出来」的团队。
- 注意：该技能的说明文档中部分章节（使用场景、使用指南、最佳实践、关键词）标注为「待完善」，具体细节与安装入口请以官方说明为准。
该技能叫什么？如何下载安装 AI 技能提升开发效率？
技能基本信息
| 项目 | 内容 |
|---|---|
| 中文名 | 六边形架构技能Skill |
| 英文名 | ddd-hexagonal-architecture |
| 技能ID | 12740 |
| 授权 | 完整条款见 LICENSE.txt |
| 触发条件 | 用户询问六边形架构、需要实现端口与适配器模式、或用六边形架构构建应用时 |
它解决什么问题
六边形架构（也叫端口与适配器架构）本身概念并不复杂：核心业务逻辑待在中间，外部世界（数据库、Web 框架、消息队列、第三方接口）通过「端口」定义契约、通过「适配器」接入实现。但真正落地时，工程师常见的困惑是：
- 端口该怎么切：哪些能力应该定义成端口，哪些属于实现细节，边界模糊就容易写成「伪六边形」。
- 领域层怎么保持干净：业务代码里混进 ORM 注解、HTTP 请求对象、框架注解，领域层被基础设施「污染」。
- 依赖方向怎么反转：接口应该定义在哪一层、由谁实现、谁持有引用，依赖倒置写反了整座架构就塌了。
- 知识来源分散：概念散落在博客、书籍、框架文档里，缺少一个能针对你当前项目上下文给出具体建议的对话对象。
这个技能的价值就在于把上述知识「打包」成一个可随时提问的助手：你描述自己的场景，它围绕端口与适配器、领域隔离、依赖反转给出指导。
一键安装 AI 技能提升开发效率的思路
AI 技能（Skill）的安装逻辑通常是「先有可运行技能的客户端，再在技能入口里完成添加」。通用步骤如下（具体命令、入口名称、是否需要账号登录等，请以官方说明为准）：
- 准备前提：确认你使用的 AI 编程助手或客户端支持技能（Skill）能力，并已完成账号登录；本地项目可正常打开。
- 打开技能入口：在客户端中找到「技能 / 插件 / 扩展」类的管理入口。
- 检索技能：用英文名
ddd-hexagonal-architecture或技能ID12740搜索，避免同名技能混淆。 - 安装并启用：按提示完成添加，确认该技能处于「已启用」状态。
- 验证是否生效：新建一个对话，提问「六边形架构里端口和适配器应该怎么划分？我的项目用了 Web 框架和 ORM，领域层该怎么保持独立？」——如果回答是围绕六边形架构、端口与适配器、领域隔离、依赖反转展开的结构化指导，而不是泛泛的分层架构科普，说明技能已被正确调用。
- 阅读授权条款：使用前请查看随技能附带的 LICENSE.txt 完整条款，确认使用范围。
该技能的主要功能和特点
- 端口与适配器模式指导：围绕「定义契约」与「实现接入」两个动作给出建议，帮你在设计阶段就把接口和实现分开，避免适配器逻辑回流到领域层。
- 领域隔离（Domain Isolation）：强调核心业务逻辑不依赖外部框架与 IO，让领域模型只表达业务规则，便于长期演进。
- 依赖反转（Dependency Inversion）：指导接口归属与依赖方向，让高层策略不依赖低层细节，而是双方都依赖抽象。
- 按需触发、不打断流程：技能描述中明确了触发条件——只有当你问到六边形架构、端口与适配器实现、或用六边形架构构建应用时才启用，不会在无关话题里强行插入。
- 概念与落地之间搭桥：不只讲「什么是六边形」，还面向「我要在当前项目里实现它」这类具体诉求。
- 与普通方案相比强在哪：
- 相比通用搜索引擎：不用自己在十几篇文章里拼凑结论，回答围绕同一套概念体系展开，前后一致。
- 相比通用大模型闲聊：因为技能自带明确的能力边界与领域词汇（端口、适配器、领域隔离、依赖反转），讨论不易跑偏到 MVC 分层或微服务拆分等相邻话题。
- 相比直接照搬框架脚手架：它给的是架构判断依据，而不是一份固定目录结构，更容易迁移到你自己的项目。
如何使用该技能？
以下为推荐的使用流程，属于通用调用方式，具体交互界面以官方说明为准。
第 1 步：确认技能已启用 按上一节的步骤完成安装与启用，再用一个明确的六边形架构问题做一次触发验证。
第 2 步：提供项目上下文 技能无法看到你未告知的信息。提问时把关键事实说清楚，例如：技术栈（语言、Web 框架、ORM）、当前分层、你想改造的模块。
第 3 步：用「场景 + 诉求」的方式提问 输入示例：
我在做一个订单系统，技术栈是 Java + Spring Boot + JPA。目前 Service 里直接调用 Repository 和第三方支付 SDK，业务逻辑和框架耦合很严重。请按六边形架构帮我分析：哪些应该是端口？入站适配器和出站适配器分别怎么放？领域层如何保持不被框架污染？依赖方向应该怎么设计？
第 4 步：阅读输出并追问细节 预期输出通常包括：端口清单与职责划分、适配器归类（入站/出站）、依赖方向说明、领域层的边界约束，以及常见的错误做法提醒。对任何一条不满意，直接追问，例如：
支付回调这块属于入站还是出站？如果第三方 SDK 的返回对象不能直接暴露给领域层，应该怎么转换？
第 5 步：落到代码结构 把结论映射到实际目录与包结构，先定义端口接口，再写适配器实现，最后让领域层只依赖抽象。注意：技能给出的是设计指导，代码仍需你自己编写与评审。
第 6 步：在评审中复用 把有价值的问答结论沉淀成团队规范条目（如「领域层禁止引入框架注解」），后续新成员可直接继承。
同类型竞品对比分析
| 方案名称 | 定位 | 核心功能 | 安装/使用门槛 | 适用场景 | 优势与不足 |
|---|---|---|---|---|---|
| 本技能（ddd-hexagonal-architecture） | 聚焦六边形架构的 AI 指导技能 | 端口与适配器、领域隔离、依赖反转的体系化建议 | 低：在支持技能的客户端中添加并启用，搜索英文名或技能ID即可，具体入口以官方说明为准 | 架构设计讨论、遗留系统解耦、代码评审前自查 | 优势：概念边界清晰、随问随答、可结合项目上下文；不足：技能说明中部分章节标注「待完善」，不直接产出可运行代码 |
| 通用 AI 助手直接提问 | 通用对话 | 覆盖面广，什么都能聊 | 极低：有账号即可 | 快速了解概念 | 优势：零门槛；不足：回答深度不稳定，容易与整洁架构、MVC 分层混淆，缺少一致的概念框架 |
| 架构书籍与框架官方文档 | 系统学习资料 | 完整理论与规范 | 中高：需要通读与消化，检索成本高 | 系统性学习、长期沉淀 | 优势：权威、体系完整；不足：不针对你的具体项目，无法追问，落地转化靠个人经验 |
| 团队自建脚手架/模板工程 | 工程实践模板 | 固定目录结构与示例代码 | 中：需自行维护与推广 | 新项目统一起手式 | 优势：开箱即用、约束强；不足：架构判断依据不显性，成员「照着写」但不懂为什么，遇到新场景容易破例 |
该技能的典型应用场景与实际体验情况
场景一：后端工程师启动新项目，先定分层再写代码 角色：负责订单/支付模块的后端工程师。痛点：一上手就写 Controller 和 Service，等业务变复杂才发现领域逻辑被拆得七零八落。使用方式：在动手前先描述技术栈与模块职责，请技能帮忙梳理端口清单与适配器归类。实际体验：上手难度低，属于「问一次就有一份设计底稿」的体验；注意点是要主动提供上下文，只说「帮我设计六边形架构」得到的回答会偏通用。
场景二：遗留系统改造，把业务逻辑从框架中「拔出来」 角色：接手老系统的开发或架构师。痛点：业务代码里到处是框架注解与第三方 SDK 调用，改动风险高、测试难写。使用方式：把当前耦合点列出来，逐个询问「这属于端口还是适配器」「转换层应该放在哪里」。实际体验：效果体现在「拆解顺序」上——先识别哪些依赖需要反转、哪些可以暂缓，避免一次性大重构；注意点是技能给的是方向性建议，改造范围仍需结合项目风险自行评估。
场景三：技术负责人做架构评审与团队规范 角色：Tech Lead。痛点：评审时只能凭经验说「这样不太对」，缺少可引用的公共语言。使用方式：把有争议的设计贴给技能，请它从领域隔离与依赖反转角度指出问题，再把结论整理成规范条目。实际体验：讨论效率明显提升，因为双方都在同一套概念下对话；注意点是需要人工判断取舍，不要把 AI 结论直接当作团队标准下发。
场景四：为领域层补单元测试做前置梳理 角色：测试或开发。痛点：业务逻辑依赖数据库与外部接口，测试只能跑集成，慢且脆。使用方式：请技能帮忙确认哪些外部依赖应通过端口抽象，从而在测试中用替代实现替换。实际体验：思路清晰、可操作；注意点是技能不生成测试代码，替换实现仍需自己写。
该技能能为用户带来的价值
- 缩短「从概念到方案」的距离：原本需要在书籍、博客、框架文档之间来回对照的问题，变成一次对话，架构讨论的启动成本显著下降。
- 降低架构认知门槛：端口与适配器、领域隔离、依赖反转这三个最容易混淆的点被反复以一致的口径解释，新人不必先啃完整本书才能参与设计讨论。
- 减少返工成本：在写代码之前把边界和依赖方向定下来，能避免「业务逻辑写进 Service 后再抽离」这类高成本返工——这一点在项目周期越长时收益越明显。
- 提升评审质量：有了共同词汇表，评审从「我觉得不好」变成「这里违反依赖反转，因为领域层直接依赖了具体实现」，沟通更高效。
- 长期价值：这套架构思想与具体框架解耦，换语言、换框架后仍然适用，属于可长期复用的工程能力沉淀。
常见问题 FAQ
Q1：这个技能怎么安装？找不到入口怎么办？
A：在支持 AI 技能（Skill）的客户端中，打开技能/插件管理入口，用英文名 ddd-hexagonal-architecture 或技能ID 12740 搜索并添加，然后启用即可。不同客户端的入口名称与安装方式可能不同，具体请以官方说明为准。
Q2：这个技能收费吗？ A：技能详情中未说明价格信息，仅提供了授权条款的位置（完整条款见 LICENSE.txt）。是否有费用、是否有使用限制，请以官方说明与授权文件为准。
Q3：它和直接问通用大模型有什么区别？ A：区别在于「边界」和「一致性」。该技能的触发条件明确限定在六边形架构、端口与适配器实现、以及用六边形架构构建应用这三类问题上，因此回答会稳定围绕端口与适配器、领域隔离、依赖反转展开，不容易跑到 MVC 分层或微服务拆分上去。
Q4：适合谁用？前端或非后端同学有必要装吗？ A：最适合后端工程师、架构师、技术负责人，以及需要做系统解耦与代码评审的人。它的核心是「业务逻辑与外部依赖如何隔离」，这个思想对任何需要长期维护的代码库都有参考价值，但具体示例层面更贴近服务端开发。
Q5：它会不会直接帮我改代码？说明里有些章节是「待完善」，还能用吗？ A：从技能描述看，它提供的是架构层面的指导，而不是自动改代码的工具，代码仍需你自己编写与验证。技能说明中「何时使用」「如何使用」「最佳实践」「关键词」等章节确实标注为待完善，意味着更细的用法约定尚未公开；但核心能力（端口与适配器、领域隔离、依赖反转）已经写清楚，正常提问即可使用，后续细节请关注官方更新。