子域识别与有界上下文分析Skill：用 DDD 战略设计把“大泥球”代码库拆成清晰业务边界
- 它是什么：一个面向架构师的领域驱动设计（DDD）战略分析技能，扫描任意代码库，识别核心域、支持子域、通用子域，并给出有界上下文划分建议。
- 它能解决什么：代码越写越乱、模块职责混杂、同一个“用户”在不同模块里含义完全不同——这些边界问题它都能定位并给出可执行的拆分建议。
- 它怎么工作：走完“提取概念 → 按通用语言分组 → 识别子域 → 评估内聚性 → 检测低内聚问题 → 映射有界上下文”六个阶段，输出域地图、内聚性矩阵、问题报告与上下文地图。
- 谁最需要它：正在做系统重构的架构师、接手遗留系统的技术负责人、准备做微服务拆分或领域建模的团队。
- 使用门槛：属于战略层分析技能，不生成代码，重点是给出结构化的架构判断，结论建议与领域专家交叉验证。
1. 该技能叫什么？如何一键安装 AI 技能提升开发效率？
基本身份信息
| 项目 | 内容 |
|---|---|
| 技能中文名 | 子域识别与有界上下文分析Skill |
| 技能英文名 | domain-analysis |
| 技能ID | 12921 |
| 技能定位 | 架构师角色、系统设计范围、输出架构类结果 |
| 许可协议 | MIT |
| 当前版本 | 1.0.0 |
| 关联技能 | 架构模式、CQRS 实现、事件溯源架构 |
它到底解决什么问题？
大多数系统的腐化不是因为代码写得不好，而是因为边界一开始就没划对。典型症状包括：
- 一个
OrderService里同时处理下单、开票、发短信、算积分，业务概念混成一锅； - “客户”在销售模块指潜在买家，在客服模块指已付费用户，同一个词两套含义，却共用一张表；
- 通用能力（邮件发送、日志、权限校验）被硬塞进核心计费逻辑里，核心域被噪声淹没；
- 想拆微服务，但没人说得清该沿哪条线切。
这个技能做的事情就是：用 DDD 战略设计的方法，把“哪些是核心业务、哪些是可外包的通用能力、语言边界在哪里”这件事，变成一份有评分、有优先级、可落地的架构分析报告。
一键安装 AI 技能提升开发效率的思路
AI 技能（Skill）的价值在于“一次安装、长期复用”——把一套专业的分析方法固化成一个可随时调用的能力，而不是每次都在对话里重新粘贴一大段提示词。安装思路如下：
- 确认前提：你使用的 AI 编程助手/客户端需要支持 AI 技能（Skill）机制，并已登录可用的账号。技能通常以技能包目录或描述文件（含 name、description、license、metadata 等字段）的形式分发。
- 找到安装入口：在该客户端的技能市场、技能目录或插件管理界面中检索。检索关键词可用技能英文名
domain-analysis或技能ID12921；如果你的客户端支持命令行安装，则使用其官方提供的技能安装命令。具体的命令格式、仓库地址与入口位置以官方说明为准。 - 完成安装：按提示确认安装，技能会被登记到本地技能列表中。若为手动安装，通常是将技能目录放入客户端的技能目录下，再重启或刷新技能列表。目录路径与刷新方式以官方说明为准。
- 验证是否生效：新建一个会话，输入一句触发语，例如“帮我分析这个代码库的领域边界，识别核心子域和有界上下文”。如果助手开始按“提取概念 → 分组 → 子域识别”的阶段推进，并准备输出域地图，说明技能已生效。若没有反应，检查技能是否处于启用状态、描述文件是否被正确读取。收费方式与额度策略以官方说明为准。
2. 该技能的主要功能和特点
- 子域三分法自动归类：内置决策树——先问“它是不是竞争优势”，再问“是否需要业务特定知识”，据此把每个业务能力归入核心域、支持子域或通用子域，并给出各自的判定指标（如核心域的特征是复杂业务逻辑、频繁变更、需要领域专家深度参与）。
- 概念提取不按技术分层：它明确反对“按 Controller / Service / DAO 分层”来理解系统，而是扫描
@Entity、*Service、*Manager、*UseCase、*Command、*Controller、*Resolver等模式，从中挑出业务概念，过滤掉纯技术工具类。 - 通用语言驱动的分组：把
Subscription、Invoice、Payment归为计费语言，把Movie、Video、Episode归为内容语言。同一术语含义发生变化的地方，就是有界上下文的分界线。 - 可量化的内聚性评分：给出明确公式——语言内聚性（0-3）+ 使用内聚性（0-3）+ 数据内聚性（0-2）+ 更改内聚性（0-2），除以 10。8-10 分为高内聚，5-7 分为中等需关注，0-4 分为低内聚。这让“感觉这里有点乱”变成了可比较的数字。
- 五类低内聚问题的规则化检测：语言不匹配、跨域依赖、混合职责、核心域里混入通用功能、边界不清晰——每条规则都配了问题示例和推荐动作（如“建议基于接口集成”“建议提取到通用子域”）。
- 上下文集成模式建议：针对识别出的上下文，给出共享内核、客户/供应商、顺从者、反腐败层、开放主机服务、发布语言六种集成模式的选型建议，避免“拆完还是一团乱”。
- 标准化的四类输出物：域地图、跨域内聚性矩阵、带优先级的低内聚性报告、有界上下文地图，格式统一，可直接放进架构文档或评审材料。
- 守住战略层边界：技能明确声明“这是战略分析，非战术实现”，只回答“存在哪些域、边界在哪”，不越界去写具体代码。
3. 如何使用该技能？
步骤一：明确分析目标与范围
先想清楚你要解决的是哪个问题：是整体领域建模，还是只想评估某个模块该不该拆。范围越小，输出越聚焦。若代码库很大，建议先指定一个子系统或一个包路径。
步骤二：用触发语唤起技能
该技能的触发关键词包括 DDD、领域驱动设计、子域、有界上下文、战略设计、域分析。你可以直接这样提问：
“按 DDD 战略设计分析这个代码库，识别核心域、支持子域和通用子域，并给出有界上下文划分建议。”
或者更聚焦地提问：
“我只关心订单和支付这两个模块，帮我判断它们应该属于同一个有界上下文还是应该拆开，并给出内聚性评分。”
步骤三：提供概念清单或让技能自行扫描
如果你能提供关键类名、模块名、业务实体清单，分析会更准。例如输入：
“订单域有 Order、OrderItem、Payment、Refund、Invoice；用户域有 User、Role、Permission、LoginLog；通知域有 SmsTemplate、MailSender。请做子域分类。”
技能会按“实体 / 服务 / 用例 / 入口点”分类这些概念，判断它们各自属于哪种业务语言。
步骤四：阅读四类输出
- 域地图：每个域标注类型（核心/支持/通用）、通用语言、业务能力、关键概念、依赖方向、内聚性得分。
- 内聚性矩阵：跨域两两对比，形如“计费 × 身份 = 2/10，问题是直接耦合，推荐改用接口”。
- 低内聚性报告：按高/中优先级列出问题位置、涉及概念、内聚性得分与修复建议。
- 有界上下文地图：每个上下文的名称、包含的子域、语言定义、集成要求、实现说明（如分离持久化、独立部署、明确 API 边界）。
步骤五：交叉验证再落地
把结论拿去和领域专家、业务方对齐。技能本身也提示“尽可能与领域专家验证”，因为战略设计最终要贴合真实业务，而不是只贴合代码结构。
步骤六：作为重构路线的输入
把高优先级问题清单直接转成重构待办项，按“先划边界、再拆代码”的顺序推进。
4. 同类型竞品对比分析
| 方案名称 | 定位 | 核心功能 | 安装/使用门槛 | 适用场景 | 优势与不足 |
|---|---|---|---|---|---|
| 子域识别与有界上下文分析Skill（domain-analysis） | AI 驱动的 DDD 战略分析技能 | 子域三分法归类、通用语言分组、内聚性量化评分、低内聚问题检测、有界上下文与集成模式建议 | 低：在支持技能的 AI 客户端中安装即可，用自然语言触发，无需额外服务 | 遗留系统梳理、微服务拆分前的边界论证、领域建模评审 | 优势：方法论完整、输出结构化、有评分可比较；不足：属战略层分析，不产出代码，结论需人工与领域专家校验 |
| 人工 DDD 领域建模工作坊 | 团队协作式领域建模 | 事件风暴、领域专家访谈、上下文映射白板推演 | 高：需组织跨职能会议，投入多人多日 | 大型系统从零建模、组织级架构共识 | 优势：业务共识最扎实；不足：成本高、周期长、依赖专家水平，难以对存量代码快速复盘 |
| 通用代码依赖/静态分析工具 | 代码结构分析 | 依赖图、循环依赖检测、模块耦合度统计 | 中：需接入构建流程或扫描配置 | 技术耦合治理、模块依赖可视化 | 优势：客观、可自动化、覆盖全量代码；不足：只看技术依赖，不理解业务语言，无法判断“核心域”，给不出业务边界建议 |
| 通用大模型直接对话 | 通用问答 | 直接让模型“看看代码讲讲架构” | 低：打开就能问 | 快速了解陌生代码库、初步答疑 | 优势：零门槛；不足：缺少固定方法论与输出结构，容易只按技术分层泛泛而谈，结果不稳定、不可复现，也没有内聚性量化标准 |
选型建议：如果目标是“快速获得一份有方法论支撑、结构统一的边界分析报告”，本技能最合适；如果目标是“让业务方真正达成共识”，工作坊不可替代；如果只想排查技术耦合，静态分析工具更直接。
5. 该技能的典型应用场景与实际体验情况
场景一：技术负责人接手遗留系统，需要快速画出领域地图
- 角色与痛点：新上任的技术负责人面对几十万行代码，没人能讲清系统到底分成几块业务，文档早已过期。
- 使用方式：把主要模块目录与核心类名交给技能，让它先提取业务概念，再按通用语言分组，最后输出域地图与内聚性矩阵。
- 实际体验：上手难度低，一次提问就能拿到结构化结果。比较实用的地方是内聚性矩阵——它会把“计费 × 身份 2/10，直接耦合”这类问题直接标出来，比人工翻代码快很多。注意事项：如果输入的概念清单不全，分组结果会有偏差，建议分模块多轮提问而非一次性投喂全库。
场景二：微服务拆分前的边界论证
- 角色与痛点：架构师主张按业务域拆服务，但团队担心拆完跨服务调用爆炸，争论不下。
- 使用方式：让技能评估候选边界的跨域依赖，并针对每条依赖给出集成模式建议（接口集成、基于事件的集成、反腐败层等）。
- 实际体验：把“我觉得该这么拆”变成了“这里有评分、有依赖清单、有集成方案”。技能还提醒“不要消除所有依赖，有些是必要的”，避免团队走向过度拆分。注意事项：它给的是战略建议，具体拆分节奏仍需结合团队规模与发布能力判断。
场景三：识别核心域，重新分配研发资源
- 角色与痛点：团队把最强的人力投在了后台管理报表上，真正的差异化业务反而人手不足。
- 使用方式：让技能对全部业务能力跑一遍子域决策树，输出核心域、支持子域、通用子域的清单，并标注每个子域的判定依据。
- 实际体验：结论直接可用于资源讨论——“核心域需要最好的开发人员”这一条让优先级争论有了共同语言。注意事项：核心域的判定本质是业务判断，技能提供的是判定框架与证据梳理，最终结论要让业务方确认。
场景四：发现核心逻辑里混入了通用功能
- 角色与痛点：计费服务里塞着邮件发送、短信模板、日志埋点，改一次计费要跑一遍通知回归。
- 使用方式：让技能针对“核心中的通用功能”这条规则做专项检测，输出高优先级问题报告。
- 实际体验：报告会精确到问题位置、涉及概念、内聚性得分和推荐动作（提取到通用子域），非常适合直接转成重构任务。注意事项：技能也说明“通用子域天然内聚性偏低”，不要把所有低分都当 bug，重点是看它是否污染了核心域。
6. 该技能能为用户带来的价值
把“架构直觉”变成“可复用的方法”：DDD 战略设计本身并不新鲜，难点在于很少有人能稳定地执行完整流程。这个技能把六个阶段、决策树、评分公式、五类问题规则、六种集成模式全部固化下来，让团队里的每个人都能跑出格式一致的分析结果。
显著压缩前期调研时间：过去要开几轮会、画几天白板才能形成的边界草图，现在可以先由技能产出一版结构化初稿，团队在此基础上做修正和决策，讨论从一开始就聚焦在具体分歧点上。
降低 DDD 的使用门槛：不需要先读完一本领域驱动设计的厚书，只要会用自然语言描述业务概念，就能拿到域地图、内聚性矩阵和上下文地图。这对中小团队尤其友好——他们往往没有专职架构师。
让架构讨论有据可依：内聚性得分（如 8-10 / 5-7 / 0-4 三档）和优先级分级，把“我觉得该拆”变成了“这里 2/10，属于高优先级问题”。长期看，这套评分还能作为技术债治理的度量基线，定期复跑观察边界质量是否改善。
为后续动作铺路：输出的上下文地图与集成模式建议，可直接衔接技能关联的架构模式、CQRS 实现、事件溯源架构等方向，形成从“划边界”到“落实现”的连续路径。
7. 常见问题 FAQ
Q1：这个技能怎么安装？需要付费吗？
A：在你所用的、支持 AI 技能（Skill）机制的客户端中，通过技能市场/技能目录检索技能英文名 domain-analysis 或技能ID 12921 完成安装，也可按官方提供的技能安装命令或手动放入技能目录。该技能自身采用 MIT 许可协议。至于客户端平台的收费与额度策略，以官方说明为准。
Q2：它会不会直接帮我改代码、拆模块？
A：不会。技能明确界定自己是“战略分析，非战术实现”，只回答存在哪些域、边界在哪、哪里有内聚性问题、推荐怎么集成，不负责生成重构代码。它输出的是域地图、内聚性矩阵、问题报告与上下文地图，落地执行仍由团队完成。
Q3：适合谁用？小项目有必要吗？
A：主要面向架构师、技术负责人、准备做微服务拆分或领域建模的团队。小项目如果只有单一业务、概念清晰，收益有限；但只要出现“同一个词在不同模块含义不同”“一个服务管了三四件事”这类迹象，就值得跑一次分析。
Q4：它和直接问通用大模型“帮我看看架构”有什么区别？
A：区别在方法论的确定性。通用对话容易按技术分层泛泛而谈，每次结果都不一样；本技能有固定的六阶段流程、子域决策树、内聚性计算公式和统一的四类输出格式，结果可复现、可比较、可直接进架构文档。
Q5：内聚性得分低就一定要拆吗？
A：不一定。技能本身特别注明：低内聚性不代表“坏”，而是“需要关注”；通用子域天然内聚性偏低属于正常现象。真正要优先处理的是高优先级问题，比如核心域里混入通用功能、域之间直接实例化对方实体这类紧耦合。最终判断建议与领域专家一起确认。