component-common-domain-detection

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Common Domain Component Detection

通用领域组件检测

This skill identifies common domain functionality that is duplicated across multiple components and suggests consolidation opportunities to reduce duplication and improve maintainability.

本技能可识别跨多个组件的重复通用领域功能，并提出合并优化方案，以减少代码重复、提升可维护性。

How to Use

使用方法

Quick Start

快速开始

Request analysis of your codebase:

"Find common domain functionality across components"
"Identify duplicate domain logic that should be consolidated"
"Detect shared classes used across multiple components"
"Analyze consolidation opportunities for common components"

请求对代码库进行分析：

"查找跨组件的通用领域功能"
"识别应合并的重复领域逻辑"
"检测跨多组件使用的共享类"
"分析通用组件的合并机会"

Usage Examples

使用示例

Example 1: Find Common Functionality

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

Example 2: Detect Duplicate Notification Logic

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

Example 3: Analyze Shared Classes

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：查找通用功能

用户: "查找跨组件的通用领域功能"

本技能将：
1. 扫描组件命名空间，查找通用模式
2. 检测跨组件使用的共享类
3. 识别重复的领域逻辑
4. 分析合并对耦合性的影响
5. 提出合并优化建议

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

用户: "是否存在多个应合并的通知组件？"

本技能将：
1. 查找所有与通知相关的组件
2. 分析它们的功能和依赖关系
3. 计算合并后的耦合影响
4. 推荐合并方案

示例3：分析共享类

用户: "查找跨多组件使用的类"

本技能将：
1. 识别被多组件导入/使用的类
2. 分类为领域功能类 vs 基础设施功能类
3. 建议合并或采用共享库方案
4. 评估对耦合性的影响

Step-by-Step Process

分步流程

Scan Components: Identify components with common namespace patterns
Detect Shared Code: Find classes/files used across components
Analyze Functionality: Determine if functionality is truly common
Assess Coupling: Calculate coupling impact before consolidation
Recommend Actions: Suggest consolidation or shared library approach

扫描组件：识别具有通用命名空间模式的组件
检测共享代码：查找跨组件使用的类/文件
分析功能：判断功能是否为真正的通用功能
评估耦合性：计算合并前的耦合影响
推荐行动：建议合并或采用共享库方案

When to Use

适用场景

Apply this skill when:

After identifying and sizing components (Pattern 1)
Before flattening components (Pattern 3)
When planning to reduce code duplication
Analyzing shared domain logic across the codebase
Preparing for component consolidation
Identifying candidates for shared services or libraries

在以下场景使用本技能：

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

Core Concepts

核心概念

Domain vs Infrastructure Functionality

领域功能 vs 基础设施功能

Domain Functionality (candidates for consolidation):

Business processing logic (notification, validation, auditing, formatting)
Common to some processes, not all
Examples: Customer notification, ticket auditing, data validation

Infrastructure Functionality (usually not consolidated here):

Operational concerns (logging, metrics, security)
Common to all processes
Examples: Logging, authentication, database connections

领域功能（合并候选）：

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

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

运维相关功能（日志、指标、安全）
适用于全部流程
示例：日志记录、身份验证、数据库连接

Common Domain Patterns

通用领域模式

Common domain functionality often appears as:

Namespace Patterns: Components ending in same leaf node

*.notification

*.audit

*.validation

*.formatting

Example:

TicketNotification

BillingNotification

SurveyNotification

Shared Classes: Same class used across multiple components
- Example:
```
SMTPConnection
```
  used by 5 different components
- Example:
```
AuditLogger
```
  used by multiple domain components
Similar Functionality: Different components doing similar things
- Example: Multiple components sending emails with slight variations
- Example: Multiple components writing audit logs

通用领域功能通常表现为以下形式：

命名空间模式：组件的叶子节点名称相同

*.notification

*.audit

*.validation

*.formatting

示例：

TicketNotification

BillingNotification

SurveyNotification

共享类：同一类被多组件使用
- 示例：
```
SMTPConnection
```
  被5个不同组件使用
- 示例：
```
AuditLogger
```
  被多个领域组件使用
相似功能：不同组件执行相似操作
- 示例：多个组件发送邮件，仅存在细微差异
- 示例：多个组件写入审计日志

Consolidation Approaches

合并方案

Shared Service:

Common functionality becomes a separate service
Other components call this service
Good for: Frequently changing logic, complex operations

Shared Library:

Common code packaged as library (JAR, DLL, npm package)
Components import and use the library
Good for: Stable functionality, simple utilities

Component Consolidation:

Merge multiple components into one
Good for: Highly related functionality, low coupling impact

共享服务：

通用功能成为独立服务
其他组件调用该服务
适用场景：频繁变更的逻辑、复杂操作

共享库：

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

组件合并：

将多个组件合并为一个
适用场景：高度相关的功能、耦合影响低

Analysis Process

分析流程

Phase 1: Identify Common Namespace Patterns

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

Scan component namespaces for common leaf node names:

Extract leaf nodes from all component namespaces

Example:

services/billing/notification

→

notification

Example:

services/ticket/notification

→

notification

Group by common leaf nodes
- Find components with same leaf node name
- Example: All components ending in
```
.notification
```
Filter out infrastructure patterns
- Exclude:
```
.util
```
  ,
```
.helper
```
  ,
```
.common
```
  (usually infrastructure)
- Focus on:
```
.notification
```
  ,
```
.audit
```
  ,
```
.validation
```
  ,
```
.formatting
```

Example Output:

markdown

undefined

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

提取叶子节点：从所有组件命名空间中提取

示例：

services/billing/notification

→

notification

示例：

services/ticket/notification

→

notification

按通用叶子节点分组
- 找出叶子节点名称相同的组件
- 示例：所有以
```
.notification
```
  结尾的组件
过滤基础设施模式
- 排除：
```
.util
```
  ,
```
.helper
```
  ,
```
.common
```
  （通常为基础设施类）
- 重点关注：
```
.notification
```
  ,
```
.audit
```
  ,
```
.validation
```
  ,
```
.formatting
```

示例输出：

markdown

undefined

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

undefined

通知组件：

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

审计组件：

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

undefined

Phase 2: Detect Shared Classes

阶段2：检测共享类

Find classes/files used across multiple components:

Scan imports/dependencies in each component
- Track which classes are imported from where
- Note classes used by multiple components
Identify shared classes
- Classes imported by 2+ components
- Exclude infrastructure classes (Logger, Config, etc.)
Classify as domain vs infrastructure
- Domain: Business logic classes (SMTPConnection, AuditLogger)
- Infrastructure: Technical utilities (Logger, DatabaseConnection)

Example Output:

markdown

undefined

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

扫描每个组件的导入/依赖
- 跟踪类的导入来源
- 记录被多组件使用的类
识别共享类
- 被2个及以上组件导入的类
- 排除基础设施类（Logger、Config等）
分类为领域类 vs 基础设施类
- 领域类：业务逻辑类（SMTPConnection、AuditLogger）
- 基础设施类：技术工具类（Logger、DatabaseConnection）

示例输出：

markdown

undefined

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)

undefined

领域类：

```
SMTPConnection
```
- 被5个组件使用（与通知相关）
```
AuditLogger
```
- 被8个组件使用（与审计相关）
```
DataFormatter
```
- 被3个组件使用（与格式化相关）

基础设施类（不纳入合并范围）：

```
Logger
```
- 被所有组件使用（基础设施）
```
Config
```
- 被所有组件使用（基础设施）

undefined

Phase 3: Analyze Functionality Similarity

阶段3：分析功能相似性

For each group of common components:

Examine functionality
- Read source code of each component
- Identify what each component does
- Note similarities and differences
Assess consolidation feasibility
- Are differences minor (configurable)?
- Can differences be abstracted?
- Is functionality truly the same?
Calculate coupling impact
- Count incoming dependencies (afferent coupling) before consolidation
- Estimate incoming dependencies after consolidation
- Compare total coupling levels

Example Analysis:

markdown

undefined

针对每组通用组件：

检查功能
- 读取每个组件的源代码
- 识别每个组件的功能
- 记录相似点和差异点
评估合并可行性
- 差异是否为细微差异（可配置）？
- 差异是否可抽象处理？
- 功能是否真正相同？
计算耦合影响
- 计算合并前的传入依赖数（传入耦合CA）
- 估算合并后的传入依赖数
- 比较总耦合水平

示例分析：

markdown

undefined

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

undefined

通知组件：

CustomerNotification：发送账单通知
TicketNotification：发送工单分配通知
SurveyNotification：发送调研邮件

相似点：均向客户发送邮件 差异点：邮件内容/模板、触发条件

合并可行性：✅ 高

差异仅存在于内容，而非机制
可通过模板/上下文进行抽象处理

undefined

Phase 4: Assess Coupling Impact

阶段4：评估耦合影响

Before recommending consolidation, analyze coupling:

Calculate current coupling
- Count components using each notification component
- Sum total incoming dependencies
Estimate consolidated coupling
- Count components that would use consolidated component
- Compare to current total
Evaluate coupling increase
- Is consolidated component too coupled?
- Does it create a bottleneck?
- Is coupling increase acceptable?

Example Coupling Analysis:

markdown

undefined

在推荐合并前，分析耦合性：

计算当前耦合性
- 统计使用每个通知组件的组件数量
- 汇总总传入依赖数
估算合并后的耦合性
- 统计将使用合并后组件的组件数量
- 与当前总数比较
评估耦合增长情况
- 合并后的组件是否耦合度过高？
- 是否会造成瓶颈？
- 耦合增长是否可接受？

示例耦合分析：

markdown

undefined

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

undefined

合并前：

CustomerNotification：被2个组件使用（CA = 2）
TicketNotification：被2个组件使用（CA = 2）
SurveyNotification：被1个组件使用（CA = 1）
总CA：5

合并后：

Notification：被5个组件使用（CA = 5）
总CA：5（无变化！）

结论：✅ 无耦合增长，可安全合并

undefined

Phase 5: Recommend Consolidation Approach

阶段5：推荐合并方案

Based on analysis, recommend approach:

Shared Service (if):

Functionality changes frequently
Complex operations
Needs independent scaling
Multiple deployment units will use it

Shared Library (if):

Stable functionality
Simple utilities
Compile-time dependency acceptable
No need for independent deployment

Component Consolidation (if):

Highly related functionality
Low coupling impact
Same deployment unit acceptable

基于分析结果，推荐合适的方案：

共享服务（适用场景）：

功能频繁变更
操作复杂
需要独立扩容
多部署单元将使用该服务

共享库（适用场景）：

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

组件合并（适用场景）：

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

Output Format

输出格式

Common Domain Components Report

通用领域组件报告

markdown

undefined

markdown

undefined

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

undefined

组件：

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

共享类：SMTPConnection（被3个组件使用）

功能分析：

均向客户发送邮件
差异点：内容/模板、触发条件
合并可行性：✅ 高

耦合分析：

合并前：CA = 2 + 2 + 1 = 5
合并后：CA = 5（无增长）
结论：✅ 可安全合并

建议：合并为

services/notification

方案：共享服务
预计规模：约4,500代码行（占代码库的5%）
收益：减少代码重复，提升可维护性

undefined

Consolidation Opportunities Table

合并机会表

markdown

undefined

markdown

undefined

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

undefined

通用功能	组件数量	当前CA	合并后CA	可行性	建议方案
通知	3个组件	5	5	✅ 高	合并为共享服务
审计	3个组件	8	12	⚠️ 中	合并，监控耦合性
验证	2个组件	3	3	✅ 高	合并为共享库

undefined

Detailed Consolidation Plan

详细合并计划

markdown

undefined

markdown

undefined

Consolidation Plan

合并计划

Priority: High

优先级：高

Notification Components →

services/notification

Steps:

Create new
```
services/notification
```
component
Move common functionality from 3 components
Create abstraction for content/templates
Update dependent components to use new service
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

通知组件 →

services/notification

步骤：

创建新的
```
services/notification
```
组件
从3个组件中迁移通用功能
为内容/模板创建抽象层
更新依赖组件，使其使用新服务
删除旧的通知组件

预计影响：

代码减少：约4,500代码行被合并
重复减少：3个组件 → 1个
耦合性：无增长（CA保持5）
可维护性：单个组件更易维护

Priority: Medium

优先级：中

Audit Components →

services/audit

Steps: [Similar format]

Expected Impact:

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

undefined

审计组件 →

services/audit

步骤： [类似格式]

预计影响：

耦合增长：CA从8→12（需监控）
收益：减少代码重复

undefined

Analysis Checklist

分析检查清单

Implementation Notes

实现说明

For Node.js/Express Applications

针对Node.js/Express应用

Common patterns to look for:

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

Shared Classes:

Check
```
require()
```
statements
Look for classes imported from other components

Example:

const SMTPConnection = require('../shared/SMTPConnection')

需关注的通用模式：

services/
├── CustomerService/
│   └── notification.js      ← 通用模式
├── TicketService/
│   └── notification.js     ← 通用模式
└── SurveyService/
    └── notification.js      ← 通用模式

共享类：

检查
```
require()
```
语句
查找从其他组件导入的类

示例：

const SMTPConnection = require('../shared/SMTPConnection')

For Java Applications

针对Java应用

Common patterns:

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

Shared Classes:

Check
```
import
```
statements
Look for classes in common packages
Example:
```
import com.company.shared.AuditLogger
```

通用模式：

com.company.billing.audit     ← 通用模式
com.company.ticket.audit      ← 通用模式
com.company.survey.audit      ← 通用模式

共享类：

检查
```
import
```
语句
查找通用包中的类
示例：
```
import com.company.shared.AuditLogger
```

Detection Strategies

检测策略

Namespace Pattern Detection:

javascript

// 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
}

Shared Class Detection:

javascript

// 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 }))
}

命名空间模式检测：

javascript

// 从命名空间提取叶子节点
function extractLeafNode(namespace) {
  const parts = namespace.split('/')
  return parts[parts.length - 1]
}

// 按通用叶子节点分组
function groupByLeafNode(components) {
  const groups = {}
  components.forEach((comp) => {
    const leaf = extractLeafNode(comp.namespace)
    if (!groups[leaf]) groups[leaf] = []
    groups[leaf].push(comp)
  })
  return groups
}

共享类检测：

javascript

// 查找被多组件使用的类
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 }))
}

Fitness Functions

适配函数

After identifying common components, create automated checks:

识别通用组件后，创建自动化检查：

Common Namespace Pattern Detection

通用命名空间模式检测

javascript

// 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',
    }))
}

javascript

// 当创建新的通用模式组件时发出警报
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',
    }))
}

Shared Class Usage Alert

共享类使用警报

javascript

// 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',
    }))
}

javascript

// 当类被多组件使用时发出警报
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',
    }))
}

Best Practices

最佳实践

Do's ✅

建议✅

Distinguish domain from infrastructure functionality
Analyze coupling impact before consolidating
Consider both shared service and shared library approaches
Look for namespace patterns AND shared classes
Verify functionality is truly similar before consolidating
Calculate coupling metrics (CA) before and after

区分领域功能与基础设施功能
合并前分析耦合影响
同时考虑共享服务和共享库方案
同时查找命名空间模式和共享类
合并前验证功能是否真正相似
合并前后计算耦合指标（CA）

Don'ts ❌

避免❌

Don't consolidate infrastructure functionality (handled separately)
Don't consolidate without analyzing coupling impact
Don't assume all common patterns should be consolidated
Don't ignore differences in functionality
Don't consolidate if coupling increase is too high
Don't mix domain and infrastructure in same analysis

不要合并基础设施功能（单独处理）
不要在未分析耦合影响的情况下进行合并
不要假设所有通用模式都应合并
不要忽略功能差异
耦合增长过高时不要合并
不要在同一分析中混合领域和基础设施功能

Common Patterns to Look For

需关注的通用模式

High Consolidation Candidates

高优先级合并候选

Notification:
```
*.notification
```
,
```
*.notify
```
,
```
*.email
```
Audit:
```
*.audit
```
,
```
*.auditing
```
,
```
*.log
```
Validation:
```
*.validation
```
,
```
*.validate
```
,
```
*.validator
```
Formatting:
```
*.format
```
,
```
*.formatter
```
,
```
*.formatting
```
Reporting:
```
*.report
```
,
```
*.reporting
```
(if similar functionality)

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

Low Consolidation Candidates

低优先级合并候选

Infrastructure:
```
*.util
```
,
```
*.helper
```
,
```
*.common
```
(usually infrastructure)
Different contexts: Same name, different business meaning
High coupling risk: Consolidation would create bottleneck

基础设施：
```
*.util
```
,
```
*.helper
```
,
```
*.common
```
（通常为基础设施）
不同上下文：名称相同但业务含义不同
高耦合风险：合并会造成瓶颈

Next Steps

后续步骤

After identifying common domain components:

Apply Flatten Components Pattern - Remove orphaned classes
Apply Determine Component Dependencies Pattern - Analyze coupling
Create Component Domains - Group components into domains
Plan Consolidation - Execute consolidation recommendations

识别通用领域组件后：

应用组件扁平化模式 - 移除孤立类
应用组件依赖分析模式 - 分析耦合性
创建组件领域 - 将组件分组为领域
执行合并 - 落实合并建议

Notes

注意事项

Common domain functionality is different from infrastructure functionality
Consolidation reduces duplication but may increase coupling
Always analyze coupling impact before consolidating
Shared services vs shared libraries have different trade-offs
Some duplication is acceptable if it reduces coupling
Not all common patterns should be consolidated

通用领域功能与基础设施功能不同
合并减少重复但可能增加耦合
合并前务必分析耦合影响
共享服务与共享库各有取舍
若能降低耦合，部分重复代码是可接受的
并非所有通用模式都应合并