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）を作成する前
• サービスベースのアーキテクチャへの移行を計画するとき
• コンポーネント間の関係とビジネスとの整合性を分析するとき
• ドメイン駆動設計の実装を準備するとき
• 構成を整理するためにコンポーネントをグループ化するとき

コアコンセプト

ドメインの定義

ドメインとは、次のようなコンポーネントの論理的なグループです。

• 独自のビジネス能力または領域を表します
• 連携して動作する関連コンポーネントを含みます
• 明確な境界と責務を持ちます
• サービスベースのアーキテクチャでドメインサービスになり得ます

例：

• 顧客ドメイン：顧客プロフィール、請求、サポート契約
• チケット管理ドメイン：チケットの作成、割り当て、ルーティング、完了
• レポートドメイン：チケットレポート、専門家レポート、財務レポート

コンポーネントとドメインの関係

1 対多：1 つのドメインに複数のコンポーネントが含まれます

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. ビジネス用語を探す

   • ビジネス用語に基づいてコンポーネントをグループ化します
   • 例：「請求」、「支払い」、「請求書」→ 財務ドメイン
   • 例：「顧客」、「プロフィール」、「契約」→ 顧客ドメイン

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. 境界を確認する

   • ドメインの境界は明確ですか？
   • コンポーネントはそれぞれ1つのドメインだけに属していますか？
   • どのドメインにも適合しないコンポーネントはありますか？

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. ドメイン境界を監視する - フィットネス関数を使用して境界を適用します

注意事項

• ドメインは技術レイヤーではなく、ビジネスケイパビリティを表す必要があります
• ドメインの特定には、ビジネス関係者との協力が必要です
• ドメインを明確にするには、名前空間のリファクタリングが重要です
• ドメインによって、コードベースをサービスベースのアーキテクチャに備えることができます
• 適切に構成されたドメインは、サービスの抽出を容易にします
• ドメイン境界は明確で、十分に文書化されている必要があります