domain-identification-grouping

域识别与分组

此技能会将架构组件归入逻辑域（业务领域），为在基于服务的架构中创建域服务做准备。

使用方法

快速开始

请求分析代码库：

• “将组件归入逻辑域”
• “为基于服务的架构识别组件所属域”
• “根据组件创建域分组”
• “分析组件分别属于哪些域”

使用示例

示例 1：域识别

User: "Group components into logical domains"

The skill will:
1. Analyze component responsibilities and relationships
2. Identify business domains based on functionality
3. Group components into domains
4. Create domain diagrams
5. Suggest namespace refactoring for domain alignment

示例 2：域分析

User: "Which domain should the billing components belong to?"

The skill will:
1. Analyze billing component functionality
2. Check relationships with other components
3. Identify appropriate domain (e.g., Customer or Financial)
4. Recommend domain assignment

示例 3：域重构

User: "What namespace refactoring is needed to align components with domains?"

The skill will:
1. Compare current component namespaces to identified domains
2. Identify misaligned components
3. Suggest namespace changes
4. Create refactoring plan

分步流程

1. 识别域：分析业务能力和组件关系
2. 对组件分组：将组件分配到合适的域
3. 验证分组：确保组件与所属域相符
4. 重构命名空间：使组件命名空间与域保持一致
5. 创建域映射：直观展示域结构和组件分组

适用场景

在以下情况下应用此技能：

• 识别、评估并分析组件依赖关系之后
• 创建域服务（模式 6）之前
• 规划向基于服务的架构迁移时
• 分析组件关系及其与业务的契合度时
• 准备实施领域驱动设计时
• 为了更好地组织组件而进行分组时

核心概念

域定义

域是由以下组件构成的逻辑分组：

• 代表一项独特的业务能力或业务领域
• 包含协同工作的相关组件
• 具有明确的边界和职责
• 可在基于服务的架构中成为域服务

示例：

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

组件与域的关系

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

Domain: Customer
├── Component: Customer Profile
├── Component: Billing Payment
├── Component: Billing History
└── Component: Support Contract

域的体现方式

域通过命名空间结构在物理层面体现：

域对齐之前：

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. 检查组件职责

   • 阅读组件名称和描述
   • 了解每个组件的功能
   • 识别业务能力

2. 寻找业务术语

   • 按业务词汇对组件分组
   • 示例：“billing”、“payment”、“invoice” → 财务域
   • 示例：“customer”、“profile”、“contract” → 客户域

3. 识别域边界

   • 业务概念在哪些地方发生变化？
   • 有哪些不同的业务领域？
   • 组件与业务能力之间有何关联？

4. 与业务相关方协作

   • 与产品负责人验证域识别结果
   • 确保域符合业务认知
   • 获取有关域边界的反馈

域识别示例：

## Identified Domains

1. **Ticketing Domain** (ss.ticket)
   - Ticket creation, assignment, routing, completion
   - Customer surveys
   - Knowledge base

2. **Customer Domain** (ss.customer)
   - Customer profile
   - Billing and payment
   - Support contracts

3. **Reporting Domain** (ss.reporting)
   - Ticket reports
   - Expert reports
   - Financial reports

4. **Admin Domain** (ss.admin)
   - User maintenance
   - Expert profile management

5. **Shared Domain** (ss.shared)
   - Login
   - Notification

阶段 2：将组件归入各个领域

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

1. 分析组件功能

   • 它支持什么业务能力？
   • 它使用什么领域术语？
   • 它与哪些其他组件相关？

2. 检查组件关系

   • 哪些组件经常一起使用？
   • 组件之间有哪些依赖关系？
   • 组件是否共享数据或工作流？

3. 分配到领域

   • 将组件放入最符合其功能的领域
   • 确保组件符合领域的业务语言
   • 验证组件关系是否支持该领域分组

4. 处理边缘情况

   • 无法明确归属的组件：进一步深入分析
   • 符合多个领域的组件：选择主要领域
   • 共享组件：可以归入 Shared 领域

组件分组示例：

## Component Domain Assignment

### Ticketing Domain (ss.ticket)

- Ticket Shared (ss.ticket.shared)
- Ticket Maintenance (ss.ticket.maintenance)
- Ticket Completion (ss.ticket.completion)
- Ticket Assign (ss.ticket.assign)
- Ticket Route (ss.ticket.route)
- KB Maintenance (ss.ticket.kb.maintenance)
- KB Search (ss.ticket.kb.search)
- Survey (ss.ticket.survey)

### Customer Domain (ss.customer)

- Customer Profile (ss.customer.profile)
- Billing Payment (ss.customer.billing.payment)
- Billing History (ss.customer.billing.history)
- Support Contract (ss.customer.supportcontract)

### Reporting Domain (ss.reporting)

- Reporting Shared (ss.reporting.shared)
- Ticket Reports (ss.reporting.tickets)
- Expert Reports (ss.reporting.experts)
- Financial Reports (ss.reporting.financial)

阶段 3：验证领域分组

确保组件适合其所属领域：

1. 检查内聚性

   • 领域中的组件是否使用相同的业务语言？
   • 组件是否经常一起使用？
   • 组件之间是否存在直接关系？

2. 验证边界

   • 领域边界是否清晰？
   • 组件是否只属于一个领域？
   • 是否存在无处归属的组件？

3. 评估完整性

   • 所有组件是否都已分配到某个领域？
   • 领域是否具有内聚性且结构良好？
   • 领域是否代表不同的业务能力？

4. 获取利益相关者验证

   • 与产品负责人一起审查领域分组
   • 确保领域符合业务认知
   • 获取有关领域边界的反馈

验证清单：

• 所有组件都已分配到某个领域
• 领域边界清晰
• 组件与所属领域契合
• 领域代表不同的业务能力
• 利益相关者已验证领域分组

阶段 4：重构命名空间以匹配领域

使组件命名空间与已识别的领域保持一致：

1. 比较当前命名空间与目标命名空间

   • 当前：services/billing/payment
   • 目标：services/customer/billing/payment
   • 变更：添加 .customer 领域节点

2. 确定所需的重构

   • 哪些组件需要更改命名空间？
   • 需要添加哪些领域节点？
   • 是否有组件已经对齐？

3. 制定重构计划

   • 列出需要更改命名空间的组件
   • 指定每个组件的目标命名空间
   • 确定重构工作的优先级

4. 执行重构

   • 更新组件命名空间
   • 更新导入项／引用
   • 验证所有引用均已更新

命名空间重构示例：

## Namespace Refactoring Plan

### Customer Domain Alignment

| Component        | Current Namespace   | Target Namespace            | Action        |
| ---------------- | ------------------- | --------------------------- | ------------- |
| Billing Payment  | ss.billing.payment  | ss.customer.billing.payment | Add .customer |
| Billing History  | ss.billing.history  | ss.customer.billing.history | Add .customer |
| Customer Profile | ss.customer.profile | ss.customer.profile         | No change     |
| Support Contract | ss.supportcontract  | ss.customer.supportcontract | Add .customer |

### Ticketing Domain Alignment

| Component      | Current Namespace | Target Namespace         | Action      |
| -------------- | ----------------- | ------------------------ | ----------- |
| KB Maintenance | ss.kb.maintenance | ss.ticket.kb.maintenance | Add .ticket |
| KB Search      | ss.kb.search      | ss.ticket.kb.search      | Add .ticket |
| Survey         | ss.survey         | ss.ticket.survey         | Add .ticket |

阶段 5：创建领域映射

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

1. 创建领域图

   • 用方框表示领域
   • 显示每个领域中的组件
   • 显示领域之间的关系

2. 记录领域结构

   • 列出领域及其组件
   • 描述领域职责
   • 注明领域边界

3. 创建领域清单

   • 列出领域和组件的表格
   • 各领域的组件数量
   • 各领域的规模指标

领域映射示例：

## Domain Map

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

## Output Format

### Domain Identification Report

```markdown
## Domain Identification

### Domain: Customer (ss.customer)

**Business Capability**: Manages customer relationships, billing, and support contracts

**Components**:
- Customer Profile (ss.customer.profile)
- Billing Payment (ss.customer.billing.payment)
- Billing History (ss.customer.billing.history)
- Support Contract (ss.customer.supportcontract)

**Component Count**: 4
**Total Size**: ~15,000 statements (18% of codebase)

**Domain Cohesion**: ✅ High
- Components share customer-related vocabulary
- Components frequently used together
- Direct relationships between components

**Boundaries**:
- Clear separation from Ticketing domain
- Clear separation from Reporting domain
- Shared components (Notification) used by all domains

组件领域分配表

## Component Domain Assignment

| Component          | Current Namespace     | Assigned Domain | Target Namespace                  |
| ------------------ | --------------------- | --------------- | --------------------------------- |
| Customer Profile   | ss.customer.profile   | Customer        | ss.customer.profile (no change)   |
| Billing Payment    | ss.billing.payment    | Customer        | ss.customer.billing.payment       |
| Ticket Maintenance | ss.ticket.maintenance | Ticketing       | ss.ticket.maintenance (no change) |
| KB Maintenance     | ss.kb.maintenance     | Ticketing       | ss.ticket.kb.maintenance          |
| Reporting Shared   | ss.reporting.shared   | Reporting       | ss.reporting.shared (no change)   |

命名空间重构计划

## Namespace Refactoring Plan

### Priority: High

**Customer Domain Alignment**

**Components to Refactor**:

1. Billing Payment: `ss.billing.payment` → `ss.customer.billing.payment`
2. Billing History: `ss.billing.history` → `ss.customer.billing.history`
3. Support Contract: `ss.supportcontract` → `ss.customer.supportcontract`

**Steps**:

1. Update namespace declarations in source files
2. Update import statements in dependent components
3. Update directory structure
4. Run tests to verify changes
5. Update documentation

**Expected Impact**:

- All customer-related components aligned under `.customer` domain
- Clearer domain boundaries
- Easier to identify domain components

领域映射可视化

## Domain Map

### Domain Structure

客户领域（ss.customer） ├── 客户资料 ├── 账单付款 ├── 账单历史记录 └── 支持合同

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

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

管理领域（ss.admin） ├── 用户维护 └── 专家资料

共享领域（ss.shared） ├── 登录 └── 通知

### Domain Relationships

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

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

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

分析清单

领域识别：

• 分析了组件职责
• 识别了业务能力
• 识别了不同的业务领域
• 与利益相关者验证了领域

组件分组：

• 将每个组件分配到一个领域
• 分析了组件之间的关系
• 确保组件符合领域词汇
• 处理了边界情况（共享组件、分配不明确）

领域验证：

• 检查了领域内部的内聚性
• 确认领域边界清晰
• 确保所有组件都已分配
• 与利益相关者进行了验证

命名空间重构：

• 比较了当前命名空间与目标命名空间
• 识别了需要重构的组件
• 制定了重构计划
• 确定了重构工作的优先级

领域映射：

• 创建了领域图
• 记录了领域结构
• 创建了领域清单表
• 记录了领域关系

实现说明

对于 Node.js/Express 应用

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

services/
├── customer/              ← Customer Domain
│   ├── profile/
│   ├── billing/
│   │   ├── payment/
│   │   └── history/
│   └── supportcontract/
├── ticket/                ← Ticketing Domain
│   ├── shared/
│   ├── maintenance/
│   ├── assign/
│   └── route/
└── reporting/             ← Reporting Domain
    ├── shared/
    ├── tickets/
    └── experts/

对于 Java 应用

通过包结构识别领域：

com.company.customer       ← Customer Domain
├── profile
├── billing
│   ├── payment
│   └── history
└── supportcontract

com.company.ticket         ← Ticketing Domain
├── shared
├── maintenance
├── assign
└── route

领域识别策略

策略 1：业务能力分析

• 识别系统提供哪些业务能力
• 按能力对组件进行分组
• 示例：“客户管理”能力 → 客户领域

策略 2：词汇分析

• 识别组件使用的业务词汇
• 将使用相同词汇的组件分组
• 示例：使用“账单”“付款”“发票”等词汇的组件 → 财务领域

策略 3：关系分析

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

策略 4：利益相关者协作

• 与产品负责人/业务分析师合作
• 借助他们对业务领域的理解
• 与他们一起验证领域边界

适用性函数

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

领域命名空间治理

// Ensure components belong to correct domain
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
}

领域边界强制检查

// Prevent components from accessing other domains directly
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: 'Cross-domain direct dependency',
        })
      }
    })
  })

  return violations
}

最佳实践

应做 ✅

• 与业务利益相关者合作识别领域
• 按业务能力而非技术层对组件进行分组
• 确保领域代表不同的业务范围
• 与利益相关者验证领域边界
• 重构命名空间，使其与领域保持一致
• 编写清晰的领域文档
• 在领域名称中使用业务语言

不应做 ❌

• 不要基于技术层（服务、控制器、模型）创建领域
• 不要将组件强行塞入不适合的领域
• 不要跳过利益相关者验证
• 不要创建太多小型领域（建议 3–7 个领域）
• 不要创建过大的领域（单体领域）
• 不要忽略不适合任何领域的组件（应分析原因）
• 不要跳过命名空间重构（这对保持清晰至关重要）

常见领域模式

业务应用中的典型领域

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

领域规模指南

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

后续步骤

创建组件领域后：

1. 应用创建领域服务模式 - 将领域提取为独立服务
2. 规划服务提取 - 为领域服务制定迁移计划
3. 实施领域服务 - 将领域迁移到单独部署的服务
4. 监控领域边界 - 使用适应度函数强制执行边界

注意事项

• 领域应代表业务能力，而非技术层
• 识别领域需要与业务相关方协作
• 命名空间重构对明确领域至关重要
• 领域可为代码库采用基于服务的架构做好准备
• 定义良好的领域有助于简化服务提取
• 领域边界应清晰明确，并有完善的文档