1. 基本信息
| 项目 | 内容 |
|---|---|
| 名称 | domain-identification-grouping-tech-leads-club-agent-skills |
| 作者/维护者 | Waldemar Neto（github.com/waldemarnt，原始作者）与 Felipe Rodrigues（github.com/felipfr，后续文档修订），发布于 Tech Leads Club 维护的技能注册库 |
| 来源链接 | https://github.com/tech-leads-club/agent-skills/tree/main/packages/skills-catalog/skills/(architecture)/domain-identification-grouping |
| 许可证 | 仓库根 LICENSE 为 MIT；本技能 SKILL.md front matter 未单独声明许可证，从仓库根许可证（数据来源：GitHub API + 直接读取 LICENSE 文件） |
| GitHub Stars | 所属技能注册库整体 5,019（数据来源：GitHub API；该数字属整个合集，不代表本技能自身热度） |
| Forks | 合集仓库整体 459 |
| 最新版本 | SKILL.md 未单独声明版本号；所属技能市场 CLI 包（@tech-leads-club/skills-catalog）版本 0.17.3（数据来源：直接读取 package.json） |
| 安装方式 | 官方 CLI 一条命令安装（npx @tech-leads-club/agent-skills） |
2. 功能介绍与亮点
domain-identification-grouping 面向一个具体问题：已存在的代码库里散落着一堆技术组件，该怎么把它们按业务边界归并成几个逻辑域，为后续拆分成独立服务做准备——不是从零设计领域模型，而是对既有代码库做结构化整理。
流程分五阶段：识别业务域（组件职责 + 业务词汇 + 组件关系三线索交叉识别，并与业务方对齐边界）→ 组件归组（分配到最贴切的域，处理归属不清/横跨多域/应归共享域三类边界情况）→ 归组校验（内聚度检查：是否共享业务词汇、是否常被一起调用、是否有直接依赖）→ 命名空间重构（给出“当前命名空间→目标命名空间”映射表与执行步骤）→ 域地图生成（域结构图与域间调用关系图）。
每个阶段都配可直接套用的输出模板（域清单、归组表、重构计划表、ASCII 域地图）与检查清单，并针对 Node.js/Java 给出命名空间组织范例；文末附两段示例性“边界护栏”代码（命名空间合规校验、跨域依赖检测），供使用者自行写入 CI，技能本身不携带可执行脚本。技能明确划清与近邻技能的边界：“识别全新领域”归 domain-analysis，本技能只做“给已有组件分组”。
3. 适用场景
所属分类：工程效率与代码质量
适合代码库组件已就绪、但命名空间和业务边界比较混乱，需要系统归并到几个清晰业务域、并产出可执行命名空间重构计划的场景。目标用户是负责单体拆分或服务化改造前期分析的后端工程师与架构师，尤其是刚做完组件盘点、下一步要决定“这些组件该怎么分组”的场景。
4. 跨 Agent 兼容性
- Claude Code：原生支持 ✅——官方 CLI 明确列入第一梯队支持列表，可通过交互式向导或
agent-skills install -s domain-identification-grouping直接安装 - Codex：支持 ✅——官方 CLI 支持列表列出 OpenAI Codex
- OpenClaw：未验证——官方支持列表未列出该 agent；SKILL.md 是标准 YAML front matter + Markdown 格式，理论上可手动复制使用，但未找到官方安装适配或第三方验证
- Hermes Agent：未验证——同上，官方支持列表未列出，也未检索到独立于该仓库之外的第三方收录证据
5. 推荐理由
多数“架构分析”类技能停在“给建议”，这一个把归组结果落到了具体的命名空间映射表和重构步骤上——不是“这些组件应该属于同一个域”这种模糊结论，而是“从 services/billing/payment 改成 services/customer/billing/payment，先改声明再改引用再跑测试”这种可直接执行的清单，且明确不跟相邻技能抢范围。
6. 评分
| 维度 | 分数 | 说明 |
|---|---|---|
| 受欢迎程度 | 5 | 该技能所属注册库共 88 个 SKILL.md，仓库整体星数不代表本技能自身热度；检索 GitHub Issue/PR 未发现独立于母仓库之外的具名第三方讨论 |
| 可用性 | 8 | 官方 CLI 一条命令安装，无需额外配置或付费依赖；SKILL.md + README + Quick Reference 共三份文档，覆盖方法论、五阶段流程、多套输出模板、Node.js/Java 实施细节；所属目录最近一次内容更新为 2026-02-26，距今约 5.5 个月 |
| 安全性 | 9 | 见下方检查清单 |
综合评分：7.33
安全检查清单逐项结果：①无可执行脚本文件，全部为 Markdown 指令；文中两段 JavaScript 是给使用者自行写入 CI 的示例片段，技能本身不执行 ②未见网络请求代码 ③无需 API Key 或凭据 ④通读全部三份文档未见可疑指令或混淆内容 ⑤独立开发者在 Tech Leads Club 技能市场发布，该市场声明全部技能发布前经 Snyk Agent Scan 静态扫描 ⑥License 明确（仓库根 MIT） ⑦所属目录最近内容更新 2026-02-26，约 5.5 个月前。
7. 跟同类 Skills 相比的优势
| 对比对象 | 定位 | 与本技能的差异 |
|---|---|---|
| legacy-migration-planner（同市场同目录） | 端到端遗留系统迁移规划：研究现状→定迁移方向→设计切割点→逐域出迁移文件→汇总路线图，含回滚与测试安全网 | 覆盖范围更广、面向“怎么把系统整体搬过去”；本技能只做归组这一件事，假定组件已经盘点完毕，产出物是命名空间层面的归组与重构计划，不涉及迁移路径或回滚设计 |
| evolutionary-modular-architecture（同市场同目录） | 面向全新平台设计的七阶段方法论，DDD 战略设计只是其第一阶段，另覆盖反腐败层、弹性工程、技术栈选型等 | 定位是“从零设计”；本技能定位是“整理已有代码库”，服务于完全不同的起点（brownfield 分析 vs greenfield 设计） |
| domain-driven-design（wondelai/skills 子技能） | 把战略与战术 DDD 方法论转化为可打分的诊断框架，教如何划定限界上下文与聚合 | 面向“该怎么设计边界”这个建模问题，输出是诊断评分；本技能面向“已有组件该怎么分组”这个结构化归类问题，输出是命名空间映射表，两者可先后配合使用 |
8. 用户评价
该技能目前在第三方平台尚无具名用户评价。
9. 安装使用方式
方式一：交互式向导
npx @tech-leads-club/agent-skills方式二：直接安装本技能
npx @tech-leads-club/agent-skills install -s domain-identification-grouping（也可全局安装 CLI 后直接用 agent-skills install -s domain-identification-grouping）
安装后无需重启。技能通过 SKILL.md 的 description 字段自动触发——当对话中出现“给这些组件分组”“按业务域组织”“识别组件归属哪个服务”“规划服务拆分”等诉求时会自动激活；也可以直接要求 agent 分析现有代码库的组件应该如何归入业务域。
10. 注意事项
- 该技能是所属注册库 88 个 SKILL.md 之一；仓库整体星数与活跃度不代表本技能自身热度
- OpenClaw 与 Hermes Agent 兼容性未获验证
- 技能假定组件盘点已经完成（即已知道代码库里有哪些组件），不包含组件识别与体量分析能力，如从零开始建议先用同注册库的组件盘点类技能
- 内容是方法论指导框架，文中的命名空间校验代码只是示例，需要使用者自行落地到具体 CI 流程