domain-analysis

サブドメインの特定と境界づけられたコンテキストの分析

このスキルでは、コードベースを分析してサブドメイン（コア、支援、汎用）を特定し、ドメイン駆動設計の戦略的設計原則に基づいて境界づけられたコンテキストを提案します。

使用するタイミング

次の場合にこのスキルを適用します。

• あらゆるコードベースのドメイン境界を分析する
• コア、支援、汎用の各サブドメインを特定する
• 問題空間からソリューション空間まで、境界づけられたコンテキストをマッピングする
• ドメインの凝集度を評価し、結合の問題を検出する
• ドメイン駆動型のリファクタリングを計画する
• コード内のビジネスケイパビリティを理解する

基本原則

サブドメインの分類

コアドメイン：競争上の優位性をもたらし、ビジネス価値が最も高く、優秀な開発者を必要とします。

• 指標：複雑なビジネスロジック、頻繁な変更、ドメインエキスパートが必要

支援サブドメイン：不可欠ですが差別化要因ではなく、ビジネス固有です。

• 指標：コアドメインを支援し、中程度の複雑さがあり、ビジネス固有のルールを持つ

汎用サブドメイン：一般的な機能を提供し、外部委託できる可能性があります。

• 指標：十分に理解された問題、差別化の度合いが低い、標準的な機能

境界づけられたコンテキスト

ドメイン用語が具体的で曖昧さのない意味を持つ、明確な言語上の境界です。

• 主な性質：技術的な境界ではなく、言語上の境界
• 重要なルール：境界の内側では、すべてのユビキタス言語の用語に曖昧さがない
• 目標：1つのサブドメインを1つの境界づけられたコンテキストに対応させる（理想形）

分析プロセス

フェーズ1：概念を抽出する

コードベースから、インフラではなくビジネス概念を探します。

1. エンティティ（識別子を持つドメインモデル）

   • パターン：@Entity、class、ドメインモデル
   • 注目点：技術的なクラスではなく、ビジネス概念

2. サービス（ビジネスオペレーション）

   • パターン：*Service、*Manager、*Handler
   • 注目点：技術的なユーティリティではなく、ビジネスロジック

3. ユースケース（ビジネスワークフロー）

   • パターン：*UseCase、*Command、*Handler
   • 注目点：CRUDではなく、ビジネスプロセス

4. コントローラー／リゾルバー（エントリーポイント）

   • パターン：*Controller、*Resolver、API エンドポイント
   • 注目点：技術的なルートではなく、ビジネスケイパビリティ

フェーズ2：ユビキタス言語でグループ化する

各概念について、次の点を判断します。

主な言語コンテキスト

• これはどのようなビジネス用語に属しますか？
• 例：
  • Subscription、Invoice、Payment → 請求の言語
  • Movie、Video、Episode → コンテンツの言語
  • User、Authentication → アイデンティティの言語

言語上の境界

• 用語の意味はどこで変わりますか？
• 同じ用語で意味が異なる場合は、別の境界づけられたコンテキストです。
• 例：「Sales」における「Customer」と「Support」における「Customer」

概念間の関係

• どの概念が自然にまとまりますか？
• どの概念がビジネス用語を共有していますか？
• どの概念が互いを参照していますか？

フェーズ3：サブドメインを特定する

サブドメインには、次の特徴があります。

• 明確なビジネスケイパビリティ
• 独立したビジネス価値
• 独自の語彙
• 複数の関連エンティティが連携している
• 一貫性のあるビジネスオペレーションの集合

一般的なドメインパターン：

• 請求／サブスクリプション：支払い、請求書、プラン
• コンテンツ／カタログ：メディア、製品、在庫
• アイデンティティ／アクセス：ユーザー、認証、認可
• 分析：メトリクス、ダッシュボード、インサイト
• 通知：メッセージ、アラート、コミュニケーション

各サブドメインを分類する：

次の判断ツリーを使います。

Is it a competitive advantage?
  YES → Core Domain
  NO → Does it require business-specific knowledge?
        YES → Supporting Subdomain
        NO → Generic Subdomain

フェーズ4：凝集度を評価する

凝集度が高いことを示す指標 ✅

• 概念がユビキタス言語を共有している
• 概念が頻繁に一緒に使われる
• 直接的なビジネス上の関係がある
• グループ内の1つの概念を変更すると、ほかの概念にも影響する
• 同じビジネス上の問題を解決する

凝集度が低いことを示す指標 ❌

• 異なるビジネス用語が混在している
• 概念が一緒に使われることがほとんどない
• 直接的なビジネス上の関係がない
• 変更してもほかの概念に影響しない
• 異なるビジネス上の問題を解決する

凝集度スコアの計算式：

Score = (
  Linguistic Cohesion (0-3) +    // Shared vocabulary
  Usage Cohesion (0-3) +         // Used together
  Data Cohesion (0-2) +          // Entity relationships
  Change Cohesion (0-2)          // Change together
) / 10

8-10: High Cohesion ✅
5-7:  Medium Cohesion ⚠️
0-4:  Low Cohesion ❌

フェーズ 5：凝集度の低い問題を検出する

ルール 1：言語の不一致

• 問題：異なるビジネス用語が混在している
• 例：同じサービス内に User（アイデンティティ）と Subscription（課金）がある
• 対応：異なる境界づけられたコンテキストへの分割を提案する

ルール 2：ドメイン間の依存関係

• 問題：ドメイン間の結合が強い
• 例：サービス A がドメイン B のエンティティを直接インスタンス化している
• 対応：インターフェースベースの連携を提案する

ルール 3：責務の混在

• 問題：1 つのクラスが複数のビジネス上の関心事を扱っている
• 例：課金とコンテンツの両方を扱うサービス
• 対応：サブドメインごとの分割を提案する

ルール 4：コア内の汎用機能

• 問題：コアとなるビジネスロジックに汎用機能が含まれている
• 例：課金サービスでのメール送信
• 対応：汎用サブドメインに切り出す

ルール 5：境界が不明確

• 問題：どのドメイン概念に属するか判断できない
• 例：複数のドメインとの関係を持つエンティティ
• 対応：境界を明確にし、必要に応じて概念を分割する

フェーズ 6：境界づけられたコンテキストを対応づける

特定した各サブドメインについて、境界づけられたコンテキストを提案します。

境界づけられたコンテキストの特徴：

• 名前がユビキタス言語を反映している
• 完全なドメインモデルを含んでいる
• 明示的な統合ポイントがある
• 言語的な境界が明確である

統合パターン：

• 共有カーネル：コンテキスト間でモデルを共有する（慎重に使用する）
• 顧客／サプライヤー：下流が上流に依存する
• 準拠者：下流が上流に準拠する
• 腐敗防止層：コンテキスト間の変換層
• オープンホストサービス：統合用に公開されたインターフェース
• 公開言語：十分に文書化された統合プロトコル

出力形式

ドメインマップ

各ドメイン／サブドメインについて：

## Domain: {Name}

**Type**: Core Domain | Supporting Subdomain | Generic Subdomain

**Ubiquitous Language**: {key business terms}

**Business Capability**: {what business problem it solves}

**Key Concepts**:

- {Concept} (Entity|Service|UseCase) - {brief description}

**Subdomains** (if applicable):

1. {Subdomain} (Core|Supporting|Generic)
   - Concepts: {list}
   - Cohesion: {score}/10
   - Dependencies: → {other domains}

**Suggested Bounded Context**: {Name}Context

- Linguistic boundary: {where terms have specific meaning}
- Integration: {how it should integrate with other contexts}

**Dependencies**:

- → {OtherDomain} via {interface/API}
- ← {OtherDomain} via {interface/API}

**Cohesion Score**: {score}/10

凝集度マトリックス

## Cross-Domain Cohesion

| Domain A | Domain B | Cohesion | Issue              | Recommendation          |
| -------- | -------- | -------- | ------------------ | ----------------------- |
| Billing  | Identity | 2/10     | ❌ Direct coupling | Use interface           |
| Content  | Billing  | 6/10     | ⚠️ Usage tracking  | Event-based integration |

凝集度の低い問題のレポート

## Issues Detected

### Priority: High

**Issue**: {description}

- **Location**: {file/class/method}
- **Problem**: {what's wrong}
- **Concepts**: {involved concepts}
- **Cohesion**: {score}/10
- **Recommendation**: {suggested fix}

### Priority: Medium

{similar format}

境界づけられたコンテキストマップ

## Suggested Bounded Contexts

### {ContextName}Context

**Contains Subdomains**:

- {Subdomain1} (Core)
- {Subdomain2} (Supporting)

**Ubiquitous Language**:

- Term: Definition in this context

**Integration Requirements**:

- Consumes from: {OtherContext} via {pattern}
- Publishes to: {OtherContext} via {pattern}

**Implementation Notes**:

- Separate persistence
- Independent deployment
- Explicit API boundaries

ベストプラクティス

推奨事項 ✅

• コード構造ではなく、ビジネス言語に着目する
• ユビキタス言語を境界の指針とする
• 凝集度を客観的に測定する
• 明確な統合ポイントを特定する
• すべてのサブドメインを分類する（コア／支援／汎用）
• まず言語的な境界を探す

避けるべきこと ❌

• 技術レイヤーでグループ化しない
• 単一のグローバルモデルを無理に作らない
• 言語の違いを無視しない
• ドメインを直接結合しない
• アーキテクチャに基づいてコンテキストを作らない
• 依存関係をすべてなくそうとしない（必要なものもあります）

分析チェックリスト

各概念について：

• どのビジネス言語に属しますか？
• どのドメイン／サブドメインの一部ですか？
• コア、支援、汎用のどれですか？
• どのような他の概念と関係がありますか？
• 依存関係は同じドメイン内にありますか？
• 言語の不一致はありますか？

各ドメインについて：

• ユビキタス言語は何ですか？
• 主要な概念は何ですか？
• サブドメインは何ですか？
• コアドメインはどれですか？
• ドメイン間の依存関係は何ですか？
• 内部の凝集度は高いですか？
• 境界は明確ですか？

凝集度分析について：

• 凝集度スコアを計算する
• 凝集度の低い領域を特定する
• ドメイン間の依存関係を対応づける
• 言語の不一致にフラグを付ける
• 強い結合を記録する
• 境界の明確化を提案する

クイックリファレンス

サブドメイン判定ツリー

Analyze business capability
└─ Is it competitive advantage?
   ├─ YES → Core Domain
   └─ NO → Is it business-specific?
      ├─ YES → Supporting Subdomain
      └─ NO → Generic Subdomain

凝集度の簡易チェック

Same vocabulary? → High linguistic cohesion
Used together? → High usage cohesion
Direct relationships? → High data cohesion
Change together? → High change cohesion

All high → Strong subdomain candidate
Mix of high/low → Review boundaries
All low → Likely wrong grouping

境界づけられたコンテキストの兆候

Clear boundary signs:
✅ Distinct Ubiquitous Language
✅ Concepts have unambiguous meaning
✅ Different meanings across contexts
✅ Clear integration points

Unclear boundary signs:
❌ Same terms with same meanings everywhere
❌ Concepts used identically across system
❌ No clear linguistic differences
❌ Tight coupling everywhere

避けるべきアンチパターン

泥団子

• すべてが相互に結び付いている
• 明確な境界がない
• 用語が混在している
• 防止策：境界づけられたコンテキストを明示する

包括的な単一モデル

• ビジネス全体に単一のモデルを使用する
• グローバルな定義が不可能になる
• 競合が生じる
• 防止策：複数のコンテキストを受け入れる

言語的概念の混在

• 同じコンテキスト内で異なる用語が使われている
• 例：Forum／Post と User／Permission
• 防止策：言語上の関連性を保つ

注意事項

• これは戦略的な分析であり、戦術的な実装ではありません
• ドメインが「どのようなものか」に焦点を当て、「どのように実装するか」には焦点を当てません
• ドメイン間に依存関係があるのは一般的です
• 凝集度が低いからといって、必ずしも「悪い」わけではありません。「注意が必要」ということです
• 汎用サブドメインの凝集度は、もともと低くなります
• 可能であれば、必ずドメインエキスパートに確認してください

検証基準

ドメインを適切に特定できている状態は、次のとおりです。

• ✅ 独自のユビキタス言語を持つ明確な境界がある
• ✅ ドメイン内の凝集度が高い
• ✅ ドメイン間の依存関係が明示されている
• ✅ ビジネス上の能力と整合している
• ✅ 課題に対する実行可能な推奨事項がある