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：共通の名前空間パターンを特定する

コンポーネントの名前空間をスキャンし、共通する末端ノード名を探します。

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

フェーズ 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)

フェーズ 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

フェーズ 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

フェーズ 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. 統合を計画する - 統合に関する推奨事項を実行します

注記

• 共通するドメイン機能は、インフラストラクチャ機能とは異なります
• 統合によって重複は減少しますが、結合が増加する可能性があります
• 統合する前に、必ず結合への影響を分析してください
• 共有サービスと共有ライブラリでは、トレードオフが異なります
• 結合を減らせるのであれば、ある程度の重複は許容できます
• 共通パターンをすべて統合すべきとは限りません