component-common-domain-detection

通用领域组件检测

此技能用于识别多个组件中重复的通用领域功能，并建议整合机会，以减少重复并提升可维护性。

使用方法

快速开始

请求分析你的代码库：

• “查找组件中的通用领域功能”
• “识别应整合的重复领域逻辑”
• “检测多个组件共用的类”
• “分析通用组件的整合机会”

使用示例

示例 1：查找通用功能

User: "Find common domain functionality across components"

The skill will:
1. Scan component namespaces for common patterns
2. Detect shared classes used across components
3. Identify duplicate domain logic
4. Analyze coupling impact of consolidation
5. Suggest consolidation opportunities

示例 2：检测重复的通知逻辑

User: "Are there multiple notification components that should be consolidated?"

The skill will:
1. Find all components with notification-related names
2. Analyze their functionality and dependencies
3. Calculate coupling impact if consolidated
4. Recommend consolidation approach

示例 3：分析共用类

User: "Find classes that are shared across multiple components"

The skill will:
1. Identify classes imported/used by multiple components
2. Classify as domain vs infrastructure functionality
3. Suggest consolidation or shared library approach
4. Assess impact on coupling

分步流程

1. 扫描组件：识别具有通用命名空间模式的组件
2. 检测共用代码：查找多个组件共用的类 / 文件
3. 分析功能：确定功能是否确实通用
4. 评估耦合：在整合前计算耦合影响
5. 建议操作：建议采用整合方案或共用库方案

适用场景

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

• 识别并评估组件规模之后（模式 1）
• 扁平化组件之前（模式 3）
• 计划减少代码重复时
• 分析代码库中的共用领域逻辑时
• 准备整合组件时
• 识别可作为共用服务或库的候选项时

核心概念

领域功能与基础设施功能

领域功能（整合候选项）：

• 业务处理逻辑（通知、验证、审计、格式化）
• 为部分流程所共用，而非全部流程
• 示例：客户通知、工单审计、数据验证

基础设施功能（通常不在此处整合）：

• 运维相关事项（日志记录、指标、安全）
• 为所有流程所共用
• 示例：日志记录、身份验证、数据库连接

常见领域模式

常见领域功能通常表现为：

1. 命名空间模式：组件以相同的叶节点结尾

   • *.notification、*.audit、*.validation、*.formatting
   • 示例：TicketNotification、BillingNotification、SurveyNotification

2. 共用类：多个组件使用同一个类

   • 示例：5 个不同组件使用 SMTPConnection
   • 示例：多个领域组件使用 AuditLogger

3. 相似功能：不同组件执行相似操作

   • 示例：多个组件发送略有差异的电子邮件
   • 示例：多个组件写入审计日志

整合方案

共用服务：

• 将通用功能转为独立服务
• 其他组件调用此服务
• 适用于：频繁变更的逻辑、复杂操作

共用库：

• 将通用代码打包为库（JAR、DLL、npm 包）
• 组件导入并使用该库
• 适用于：稳定的功能、简单的工具

组件整合：

• 将多个组件合并为一个
• 适用于：高度相关的功能、耦合影响较低的情况

分析流程

阶段 1：识别通用命名空间模式

扫描组件命名空间，查找通用叶节点名称：

1. 提取叶节点，从所有组件命名空间中提取

   • 示例：services/billing/notification → notification
   • 示例：services/ticket/notification → notification

2. 按通用叶节点分组

   • 查找叶节点名称相同的组件
   • 示例：所有以 .notification 结尾的组件

3. 筛除基础设施模式

   • 排除：.util、.helper、.common（通常属于基础设施）
   • 关注：.notification、.audit、.validation、.formatting

示例输出：

## Common Namespace Patterns Found

**Notification Components**:

- services/customer/notification
- services/ticket/notification
- services/survey/notification

**Audit Components**:

- services/billing/audit
- services/ticket/audit
- services/survey/audit

Phase 2：检测共享类

查找被多个组件使用的类/文件：

1. 扫描各组件中的导入项/依赖

   • 追踪从何处导入了哪些类
   • 记录被多个组件使用的类

2. 识别共享类

   • 被 2 个或更多组件导入的类
   • 排除基础设施类（Logger、Config 等）

3. 区分领域类与基础设施类

   • 领域类：业务逻辑类（SMTPConnection、AuditLogger）
   • 基础设施类：技术工具类（Logger、DatabaseConnection）

输出示例：

## Shared Classes Found

**Domain Classes**:

- `SMTPConnection` - Used by 5 components (notification-related)
- `AuditLogger` - Used by 8 components (audit-related)
- `DataFormatter` - Used by 3 components (formatting-related)

**Infrastructure Classes** (exclude from consolidation):

- `Logger` - Used by all components (infrastructure)
- `Config` - Used by all components (infrastructure)

Phase 3：分析功能相似性

对于每组常见组件：

1. 检查功能

   • 阅读各组件的源代码
   • 确定各组件的功能
   • 记录相似之处和差异

2. 评估整合可行性

   • 差异是否较小（可配置）？
   • 能否对差异进行抽象？
   • 功能是否真的相同？

3. 计算耦合影响

   • 计算整合前的传入依赖（传入耦合）数量
   • 估算整合后的传入依赖数量
   • 比较总耦合度

分析示例：

## Functionality Analysis

**Notification Components**:

- CustomerNotification: Sends billing notifications
- TicketNotification: Sends ticket assignment notifications
- SurveyNotification: Sends survey emails

**Similarities**: All send emails to customers
**Differences**: Email content/templates, triggers

**Consolidation Feasibility**: ✅ High

- Differences are in content, not mechanism
- Can be abstracted with templates/context

Phase 4：评估耦合影响

在建议整合之前，先分析耦合：

1. 计算当前耦合度

   • 统计使用各通知组件的组件数量
   • 汇总传入依赖总数

2. 估算整合后的耦合度

   • 统计将使用整合后组件的组件数量
   • 与当前总数进行比较

3. 评估耦合度增长

   • 整合后的组件是否耦合过高？
   • 是否会造成瓶颈？
   • 耦合度增长是否可以接受？

耦合分析示例：

## Coupling Impact Analysis

**Before Consolidation**:

- CustomerNotification: Used by 2 components (CA = 2)
- TicketNotification: Used by 2 components (CA = 2)
- SurveyNotification: Used by 1 component (CA = 1)
- **Total CA**: 5

**After Consolidation**:

- Notification: Used by 5 components (CA = 5)
- **Total CA**: 5 (same!)

**Verdict**: ✅ No coupling increase, safe to consolidate

Phase 5：建议整合方案

根据分析结果，建议采用以下方案：

共享服务（适用于以下情况）：

• 功能经常变化
• 操作复杂
• 需要独立扩展
• 多个部署单元将使用它

共享库（适用于以下情况）：

• 功能稳定
• 简单工具
• 可以接受编译时依赖
• 无需独立部署

组件整合（适用于以下情况）：

• 功能高度相关
• 耦合影响较低
• 可以接受部署在同一单元

输出格式

常见领域组件报告

## Common Domain Components Found

### Notification Functionality

**Components**:

- services/customer/notification (2% - 1,433 statements)
- services/ticket/notification (2% - 1,765 statements)
- services/survey/notification (2% - 1,299 statements)

**Shared Classes**: SMTPConnection (used by all 3)

**Functionality Analysis**:

- All send emails to customers
- Differences: Content/templates, triggers
- Consolidation Feasibility: ✅ High

**Coupling Analysis**:

- Before: CA = 2 + 2 + 1 = 5
- After: CA = 5 (no increase)
- Verdict: ✅ Safe to consolidate

**Recommendation**: Consolidate into `services/notification`

- Approach: Shared Service
- Expected Size: ~4,500 statements (5% of codebase)
- Benefits: Reduced duplication, easier maintenance

整合机会表

## Consolidation Opportunities

| Common Functionality | Components   | Current CA | After CA | Feasibility | Recommendation                |
| -------------------- | ------------ | ---------- | -------- | ----------- | ----------------------------- |
| Notification         | 3 components | 5          | 5        | ✅ High     | Consolidate to shared service |
| Audit                | 3 components | 8          | 12       | ⚠️ Medium   | Consolidate, monitor coupling |
| Validation           | 2 components | 3          | 3        | ✅ High     | Consolidate to shared library |

详细整合计划

## Consolidation Plan

### Priority: High

**Notification Components** → `services/notification`

**Steps**:

1. Create new `services/notification` component
2. Move common functionality from 3 components
3. Create abstraction for content/templates
4. Update dependent components to use new service
5. Remove old notification components

**Expected Impact**:

- Reduced code: ~4,500 statements consolidated
- Reduced duplication: 3 components → 1
- Coupling: No increase (CA stays at 5)
- Maintenance: Easier to maintain single component

### Priority: Medium

**Audit Components** → `services/audit`

**Steps**:
[Similar format]

**Expected Impact**:

- Coupling increase: CA 8 → 12 (monitor)
- Benefits: Reduced duplication

分析检查清单

常见模式检测：

• 扫描所有组件命名空间，查找常见叶节点
• 找出名称结尾相同的组件
• 过滤掉基础设施模式
• 对相似组件进行分组

共享类检测：

• 扫描各组件中的导入项/依赖
• 找出被多个组件使用的类
• 区分领域类与基础设施类
• 记录共享类的使用情况

功能分析：

• 检查常见组件的源代码
• 找出相似之处和差异
• 评估整合可行性
• 确定差异是否可以抽象

耦合评估：

• 计算各组件当前的耦合度（CA）
• 估算整合后的耦合度
• 比较总耦合度
• 评估耦合度增长是否可以接受

建议：

• 建议整合方案（服务/库/合并）
• 按影响对建议排序
• 制定包含具体步骤的整合计划
• 估算预期收益和风险

实施说明

对于 Node.js/Express 应用

需要查找的常见模式：

services/
├── CustomerService/
│   └── notification.js      ← Common pattern
├── TicketService/
│   └── notification.js     ← Common pattern
└── SurveyService/
    └── notification.js      ← Common pattern

共享类：

• 检查 require() 语句
• 查找从其他组件导入的类
• 示例：const SMTPConnection = require('../shared/SMTPConnection')

对于 Java 应用

常见模式：

com.company.billing.audit     ← Common pattern
com.company.ticket.audit      ← Common pattern
com.company.survey.audit      ← Common pattern

共享类：

• 检查 import 语句
• 查找常见包中的类
• 示例：import com.company.shared.AuditLogger

检测策略

命名空间模式检测：

// Extract leaf nodes from namespaces
function extractLeafNode(namespace) {
  const parts = namespace.split('/')
  return parts[parts.length - 1]
}

// Group by common leaf nodes
function groupByLeafNode(components) {
  const groups = {}
  components.forEach((comp) => {
    const leaf = extractLeafNode(comp.namespace)
    if (!groups[leaf]) groups[leaf] = []
    groups[leaf].push(comp)
  })
  return groups
}

共享类检测：

// Find classes used by multiple components
function findSharedClasses(components) {
  const classUsage = {}
  components.forEach((comp) => {
    comp.imports.forEach((imp) => {
      if (!classUsage[imp]) classUsage[imp] = []
      classUsage[imp].push(comp.name)
    })
  })

  return Object.entries(classUsage)
    .filter(([cls, users]) => users.length > 1)
    .map(([cls, users]) => ({ class: cls, usedBy: users }))
}

适应度函数

识别出常见组件后，创建自动化检查：

常见命名空间模式检测

// Alert if new components with common patterns are created
function checkCommonPatterns(components, exclusionList = []) {
  const leafNodes = {}
  components.forEach((comp) => {
    const leaf = extractLeafNode(comp.namespace)
    if (!exclusionList.includes(leaf)) {
      if (!leafNodes[leaf]) leafNodes[leaf] = []
      leafNodes[leaf].push(comp.name)
    }
  })

  return Object.entries(leafNodes)
    .filter(([leaf, comps]) => comps.length > 1)
    .map(([leaf, comps]) => ({
      pattern: leaf,
      components: comps,
      suggestion: 'Consider consolidating these components',
    }))
}

共享类使用警报

// Alert if class is used by multiple components
function checkSharedClasses(components, exclusionList = []) {
  const classUsage = {}
  components.forEach((comp) => {
    comp.imports.forEach((imp) => {
      if (!exclusionList.includes(imp)) {
        if (!classUsage[imp]) classUsage[imp] = []
        classUsage[imp].push(comp.name)
      }
    })
  })

  return Object.entries(classUsage)
    .filter(([cls, users]) => users.length > 1)
    .map(([cls, users]) => ({
      class: cls,
      usedBy: users,
      suggestion: 'Consider extracting to shared component or library',
    }))
}

最佳实践

应该做 ✅

• 区分领域功能与基础设施功能
• 在整合前分析耦合影响
• 同时考虑共享服务和共享库两种方式
• 查找命名空间模式和共享类
• 在整合前确认功能确实相似
• 计算整合前后的耦合度指标（CA）

不应该做 ❌

• 不要整合基础设施功能（需单独处理）
• 不要在未分析耦合影响的情况下进行整合
• 不要假设所有常见模式都应该整合
• 不要忽略功能差异
• 如果耦合度增加过高，不要整合
• 不要在同一分析中混合领域和基础设施

需要留意的常见模式

高度适合整合的候选项

• 通知：*.notification、*.notify、*.email
• 审计：*.audit、*.auditing、*.log
• 验证：*.validation、*.validate、*.validator
• 格式化：*.format、*.formatter、*.formatting
• 报告：*.report、*.reporting（如果功能相似）

不适合整合的候选项

• 基础设施：*.util、*.helper、*.common（通常属于基础设施）
• 不同上下文：名称相同，业务含义不同
• 高耦合风险：整合会造成瓶颈

后续步骤

识别出常见领域组件后：

1. 应用展平组件模式 - 移除孤立类
2. 应用确定组件依赖关系模式 - 分析耦合
3. 创建组件领域 - 将组件归入各个领域
4. 规划整合 - 执行整合建议

注释

• 常见领域功能不同于基础设施功能
• 整合可以减少重复，但可能增加耦合
• 整合前务必分析耦合影响
• 共享服务与共享库各有不同的权衡
• 如果能降低耦合，允许存在一定程度的重复
• 并非所有常见模式都应该整合