name: 领域识别与分组 description: 将组件分组到逻辑领域，以准备服务基于架构。在创建组件领域、按业务功能分组组件、规划领域服务、分析组件关系或当用户询问领域分组、组件领域或领域识别时使用。

领域识别与分组

这个技能将架构组件分组到逻辑领域（业务领域），为在服务基于架构中创建领域服务做准备。

如何使用

快速开始

请求分析您的代码库：

“将组件分组到逻辑领域”
“为服务基于架构识别组件领域”
“从组件创建领域分组”
“分析哪些组件属于哪些领域”

使用示例

示例1：领域识别

用户：“将组件分组到逻辑领域”

技能将：
1. 分析组件职责和关系
2. 基于功能识别业务领域
3. 将组件分组到领域
4. 创建领域图
5. 建议命名空间重构以对齐领域

示例2：领域分析

用户：“计费组件应该属于哪个领域？”

技能将：
1. 分析计费组件功能
2. 检查与其他组件的关系
3. 识别适当领域（例如，客户或财务）
4. 推荐领域分配

示例3：领域重构

用户：“需要哪些命名空间重构来将组件与领域对齐？”

技能将：
1. 比较当前组件命名空间与识别出的领域
2. 识别未对齐的组件
3. 建议命名空间更改
4. 创建重构计划

逐步流程

识别领域：分析业务能力和组件关系
分组组件：将组件分配到适当领域
验证分组：确保组件在其领域中合适
重构命名空间：将组件命名空间与领域对齐
创建领域地图：可视化领域结构和组件分组

何时使用

应用此技能当：

在识别、大小分析和分析组件依赖之后
在创建领域服务（模式6）之前
当规划服务基于架构迁移时
分析组件关系和业务对齐时
为领域驱动设计实施做准备时
为更好地组织分组组件时

核心概念

领域定义

一个领域是组件的逻辑分组，它：

代表一个独特的业务能力或领域
包含相关组件一起工作
有清晰的边界和职责
可以在服务基于架构中成为领域服务

示例：

客户领域：客户档案、计费、支持合同
工单领域：工单创建、分配、路由、完成
报告领域：工单报告、专家报告、财务报告

组件领域关系

一对多：单个领域包含多个组件

领域：客户
├── 组件：客户档案
├── 组件：计费支付
├── 组件：计费历史
└── 组件：支持合同

领域表现

领域通过命名空间结构物理表现：

在领域对齐之前：

services/billing/payment
services/billing/history
services/customer/profile
services/supportcontract

在领域对齐之后：

services/customer/billing/payment
services/customer/billing/history
services/customer/profile
services/customer/supportcontract

注意所有客户相关功能如何在.customer领域下分组。

分析流程

阶段1：识别业务领域

分析代码库以识别独特业务领域：

检查组件职责
- 读取组件名称和描述
- 理解每个组件的作用
- 识别业务能力
寻找业务语言
- 按业务词汇分组组件
- 示例：“计费”、“支付”、“发票” → 财务领域
- 示例：“客户”、“档案”、“合同” → 客户领域
识别领域边界
- 业务概念在哪里变化？
- 什么是独特的业务领域？
- 组件如何与业务能力相关？
与业务利益相关者协作
- 与产品所有者验证领域识别
- 确保领域与业务理解对齐
- 获取关于领域边界的反馈

示例领域识别：

## 识别出的领域

1. **工单领域** (ss.ticket)
   - 工单创建、分配、路由、完成
   - 客户调查
   - 知识库

2. **客户领域** (ss.customer)
   - 客户档案
   - 计费和支付
   - 支持合同

3. **报告领域** (ss.reporting)
   - 工单报告
   - 专家报告
   - 财务报告

4. **管理领域** (ss.admin)
   - 用户维护
   - 专家档案管理

5. **共享领域** (ss.shared)
   - 登录
   - 通知

阶段2：将组件分组到领域

将每个组件分配到适当领域：

分析组件功能
- 它支持什么业务能力？
- 它使用什么领域词汇？
- 它与其他组件有什么关联？
检查组件关系
- 哪些组件经常一起使用？
- 组件之间的依赖是什么？
- 组件共享数据或工作流吗？
分配到领域
- 将组件放入最适合其功能的领域
- 确保组件与领域的业务语言对齐
- 验证组件关系支持领域分组
处理边缘案例
- 不清晰拟合的组件：更深入分析
- 拟合多个领域的组件：选择主要领域
- 共享组件：可能属于共享领域

示例组件分组：

## 组件领域分配

### 工单领域 (ss.ticket)

- 工单共享 (ss.ticket.shared)
- 工单维护 (ss.ticket.maintenance)
- 工单完成 (ss.ticket.completion)
- 工单分配 (ss.ticket.assign)
- 工单路由 (ss.ticket.route)
- 知识库维护 (ss.ticket.kb.maintenance)
- 知识库搜索 (ss.ticket.kb.search)
- 调查 (ss.ticket.survey)

### 客户领域 (ss.customer)

- 客户档案 (ss.customer.profile)
- 计费支付 (ss.customer.billing.payment)
- 计费历史 (ss.customer.billing.history)
- 支持合同 (ss.customer.supportcontract)

### 报告领域 (ss.reporting)

- 报告共享 (ss.reporting.shared)
- 工单报告 (ss.reporting.tickets)
- 专家报告 (ss.reporting.experts)
- 财务报告 (ss.reporting.financial)

阶段3：验证领域分组

确保组件在其分配的领域中合适：

检查内聚性
- 领域中的组件共享业务语言吗？
- 组件经常一起使用吗？
- 组件有直接关系吗？
验证边界
- 领域边界清晰吗？
- 组件只属于一个领域吗？
- 有不适配任何地方的组件吗？
评估完整性
- 所有组件都分配到领域了吗？
- 领域内聚且形式良好吗？
- 领域代表独特业务能力吗？
获取利益相关者验证
- 与产品所有者审查领域分组
- 确保领域与业务理解对齐
- 获取关于领域边界的反馈

验证清单：

[ ] 所有组件分配到领域
[ ] 领域有清晰边界
[ ] 组件在其领域中合适
[ ] 领域代表独特业务能力
[ ] 利益相关者验证领域分组

阶段4：重构命名空间以对齐领域

将组件命名空间与识别出的领域对齐：

比较当前与目标命名空间
- 当前：services/billing/payment
- 目标：services/customer/billing/payment
- 更改：添加.customer领域节点
识别需要的重构
- 哪些组件需要命名空间更改？
- 需要添加哪些领域节点？
- 有已经对齐的组件吗？
创建重构计划
- 列出需要命名空间更改的组件
- 为每个指定目标命名空间
- 优先重构工作
执行重构
- 更新组件命名空间
- 更新导入/引用
- 验证所有引用已更新

示例命名空间重构：

## 命名空间重构计划

### 客户领域对齐

| 组件        | 当前命名空间   | 目标命名空间            | 操作        |
| ---------------- | ------------------- | --------------------------- | ------------- |
| 计费支付  | ss.billing.payment  | ss.customer.billing.payment | 添加 .customer |
| 计费历史  | ss.billing.history  | ss.customer.billing.history | 添加 .customer |
| 客户档案 | ss.customer.profile | ss.customer.profile         | 无更改     |
| 支持合同 | ss.supportcontract  | ss.customer.supportcontract | 添加 .customer |

### 工单领域对齐

| 组件      | 当前命名空间 | 目标命名空间         | 操作      |
| -------------- | ----------------- | ------------------------ | ----------- |
| 知识库维护 | ss.kb.maintenance | ss.ticket.kb.maintenance | 添加 .ticket |
| 知识库搜索 | ss.kb.search      | ss.ticket.kb.search      | 添加 .ticket |
| 调查         | ss.survey         | ss.ticket.survey         | 添加 .ticket |

阶段5：创建领域地图

可视化领域结构和组件分组：

创建领域图
- 将领域显示为框
- 显示每个领域内的组件
- 显示领域之间的关系
文档化领域结构
- 列出领域及其组件
- 描述领域职责
- 注意领域边界
创建领域清单
- 领域和组件表
- 每个领域的组件计数
- 每个领域的大小指标

示例领域地图：

## 领域地图

┌─────────────────────────────────────┐ │ 工单领域 (ss.ticket) │ ├─────────────────────────────────────┤ │ • 工单共享 │ │ • 工单维护 │ │ • 工单完成 │ │ • 工单分配 │ │ • 工单路由 │ │ • 知识库维护 │ │ • 知识库搜索 │ │ • 调查 │ └─────────────────────────────────────┘ │ │ 使用 ▼ ┌─────────────────────────────────────┐ │ 客户领域 (ss.customer) │ ├─────────────────────────────────────┤ │ • 客户档案 │ │ • 计费支付 │ │ • 计费历史 │ │ • 支持合同 │ └─────────────────────────────────────┘


## 输出格式

### 领域识别报告

```markdown
## 领域识别

### 领域：客户 (ss.customer)

**业务能力**：管理客户关系、计费和支持合同

**组件**：
- 客户档案 (ss.customer.profile)
- 计费支付 (ss.customer.billing.payment)
- 计费历史 (ss.customer.billing.history)
- 支持合同 (ss.customer.supportcontract)

**组件计数**：4
**总大小**：约15,000条语句（代码库的18%）

**领域内聚性**：✅ 高
- 组件共享客户相关词汇
- 组件经常一起使用
- 组件之间有直接关系

**边界**：
- 与工单领域清晰分离
- 与报告领域清晰分离
- 共享组件（通知）被所有领域使用

组件领域分配表

## 组件领域分配

| 组件          | 当前命名空间     | 分配领域 | 目标命名空间                  |
| ------------------ | --------------------- | --------------- | --------------------------------- |
| 客户档案   | ss.customer.profile   | 客户        | ss.customer.profile（无更改）   |
| 计费支付    | ss.billing.payment    | 客户        | ss.customer.billing.payment       |
| 工单维护 | ss.ticket.maintenance | 工单       | ss.ticket.maintenance（无更改） |
| 知识库维护     | ss.kb.maintenance     | 工单       | ss.ticket.kb.maintenance          |
| 报告共享   | ss.reporting.shared   | 报告       | ss.reporting.shared（无更改）   |

命名空间重构计划

## 命名空间重构计划

### 优先级：高

**客户领域对齐**

**要重构的组件**：

1. 计费支付：`ss.billing.payment` → `ss.customer.billing.payment`
2. 计费历史：`ss.billing.history` → `ss.customer.billing.history`
3. 支持合同：`ss.supportcontract` → `ss.customer.supportcontract`

**步骤**：

1. 在源文件中更新命名空间声明
2. 在依赖组件中更新导入语句
3. 更新目录结构
4. 运行测试以验证更改
5. 更新文档

**预期影响**：

- 所有客户相关组件在`.customer`领域下对齐
- 更清晰的领域边界
- 更容易识别领域组件

领域地图可视化

## 领域地图

### 领域结构

客户领域 (ss.customer) ├── 客户档案 ├── 计费支付 ├── 计费历史 └── 支持合同

工单领域 (ss.ticket) ├── 工单共享 ├── 工单维护 ├── 工单完成 ├── 工单分配 ├── 工单路由 ├── 知识库维护 ├── 知识库搜索 └── 调查

报告领域 (ss.reporting) ├── 报告共享 ├── 工单报告 ├── 专家报告 └── 财务报告

管理领域 (ss.admin) ├── 用户维护 └── 专家档案

共享领域 (ss.shared) ├── 登录 └── 通知


### 领域关系

工单领域 │ 使用 ├─→ 共享领域（登录、通知） └─→ 客户领域（客户档案）

客户领域 │ 使用 └─→ 共享领域（登录、通知）

报告领域 │ 使用 ├─→ 工单领域（工单数据） ├─→ 客户领域（客户数据） └─→ 共享领域（登录）

分析清单

领域识别：

[ ] 分析了组件职责
[ ] 识别了业务能力
[ ] 识别了独特业务领域
[ ] 与利益相关者验证了领域

组件分组：

[ ] 将每个组件分配到领域
[ ] 分析了组件关系
[ ] 确保组件与领域词汇拟合
[ ] 处理了边缘案例（共享组件、不清晰分配）

领域验证：

[ ] 检查了领域内内聚性
[ ] 验证了领域边界清晰
[ ] 确保所有组件已分配
[ ] 与利益相关者验证了

命名空间重构：

[ ] 比较了当前与目标命名空间
[ ] 识别了需要重构的组件
[ ] 创建了重构计划
[ ] 优先了重构工作

领域映射：

[ ] 创建了领域图
[ ] 文档化了领域结构
[ ] 创建了领域清单表
[ ] 文档化了领域关系

实施注释

对于Node.js/Express应用程序

领域通常在services/目录中组织：

services/
├── customer/              ← 客户领域
│   ├── profile/
│   ├── billing/
│   │   ├── payment/
│   │   └── history/
│   └── supportcontract/
├── ticket/                ← 工单领域
│   ├── shared/
│   ├── maintenance/
│   ├── assign/
│   └── route/
└── reporting/             ← 报告领域
    ├── shared/
    ├── tickets/
    └── experts/

对于Java应用程序

领域通过包结构识别：

com.company.customer       ← 客户领域
├── profile
├── billing
│   ├── payment
│   └── history
└── supportcontract

com.company.ticket         ← 工单领域
├── shared
├── maintenance
├── assign
└── route

领域识别策略

策略1：业务能力分析

识别系统提供的业务能力
按能力分组组件
示例：“客户管理”能力 → 客户领域

策略2：词汇分析

识别组件使用的业务词汇
分组共享相同词汇的组件
示例：使用“计费”、“支付”、“发票”的组件 → 财务领域

策略3：关系分析

识别经常一起使用的组件
分组有强关系的组件
示例：共享数据/工作流的组件 → 相同领域

策略4：利益相关者协作

与产品所有者/业务分析师合作
使用他们对业务领域的理解
与他们验证领域边界

适应度函数

创建领域后，创建自动检查：

领域命名空间治理

// 确保组件属于正确领域
function validateDomainNamespaces(components, domainRules) {
  const violations = []

  components.forEach((comp) => {
    const domain = identifyDomain(comp.namespace)
    const expectedDomain = domainRules[comp.name]

    if (domain !== expectedDomain) {
      violations.push({
        component: comp.name,
        currentDomain: domain,
        expectedDomain: expectedDomain,
        namespace: comp.namespace,
      })
    }
  })

  return violations
}

领域边界执行

// 防止组件直接访问其他领域
function enforceDomainBoundaries(components) {
  const violations = []

  components.forEach((comp) => {
    comp.imports.forEach((imp) => {
      const importedDomain = identifyDomain(imp)
      const componentDomain = identifyDomain(comp.namespace)

      if (importedDomain !== componentDomain && importedDomain !== 'shared') {
        violations.push({
          component: comp.name,
          domain: componentDomain,
          importsFrom: imp,
          importedDomain: importedDomain,
          issue: '跨领域直接依赖',
        })
      }
    })
  })

  return violations
}

最佳实践

做✅

与业务利益相关者协作识别领域
按业务能力分组组件，而不是技术层
确保领域代表独特业务领域
与利益相关者验证领域边界
重构命名空间以与领域对齐
创建清晰的领域文档
在领域名称中使用业务语言

不做❌

不要基于技术层创建领域（服务、控制器、模型）
不要强迫组件进入不拟合的领域
不要跳过利益相关者验证
不要创建太多小领域（目标3-7个领域）
不要创建太大的领域（单体领域）
不要忽略不拟合的组件（分析原因）
不要跳过命名空间重构（对清晰度关键）

常见领域模式

业务应用中的典型领域

客户领域：客户管理、档案、关系
产品领域：产品目录、库存、定价
订单领域：订单处理、履行、发货
计费领域：发票、支付、财务交易
报告领域：报告、分析、仪表板
管理领域：用户管理、系统配置
共享领域：常见功能（登录、通知、工具）

领域大小指南

小领域：2-4个组件
中领域：5-8个组件
大领域：9-15个组件
太大：>15个组件（考虑拆分）

下一步

创建组件领域后：

应用创建领域服务模式 - 提取领域到单独服务
规划服务提取 - 创建领域服务迁移计划
实施领域服务 - 将领域移动到单独部署的服务
监控领域边界 - 使用适应度函数执行边界

注释

领域应代表业务能力，而不是技术层
领域识别需要与业务利益相关者协作
命名空间重构对领域清晰度关键
领域为服务基于架构准备代码库
形式良好的领域使服务提取更容易
领域边界应清晰且良好文档化