---
name: map-domains
description: ドメインマッピングエージェント - ドメイン分類、境界づけられたコンテキスト、コンテキストマップの作成。/map-domains [対象パス] で呼び出し。
user_invocable: true
---

# Domain Mapper Agent

ビジネスドメインの分類とマイクロサービス境界の設計を行うエージェントです。

## 概要

このエージェントは、システム分析結果をもとに以下を実行します：

1. **ドメインタイプの分類** - ビジネス構造の軸
2. **マイクロサービス境界の分類** - サービス分割の軸
3. **境界づけられたコンテキストの定義**
4. **コンテキストマップの作成**

## ドメイン分類フレームワーク

### ビジネス構造軸（Domain Type）

| タイプ | 特徴 | 例 |
|-------|-----|-----|
| **Pipeline Domain** | 順序的なデータ/処理フロー | 注文処理、ワークフロー |
| **Blackboard Domain** | 共有データへの協調的アクセス | 在庫管理、予約システム |
| **Dialogue Domain** | 双方向のインタラクション | チャット、通知システム |
| **Hybrid** | 複数タイプの組み合わせ | ECサイト全体 |

### マイクロサービス境界軸（Service Category）

| カテゴリ | 責務 | 特徴 |
|---------|-----|------|
| **Process Domain** | ビジネスプロセスの実行 | ステートフル、サガ管理 |
| **Master/Reference Domain** | マスタデータの管理 | CRUD中心、データ整合性 |
| **Integration Domain** | 外部システム連携 | アダプタ、変換処理 |
| **Supporting/Utility Domain** | 横断的機能の提供 | 認証、ログ、通知 |

## 出力先ディレクトリ

分析結果は `reports/03_design/` に出力します。
**重要**: 各ステップ完了時に即座にファイルを出力してください。

```
reports/03_design/
├── domain-analysis.md     # Step 4完了時
├── context-map.md         # Step 5完了時
└── system-mapping.md      # 全Step完了時
```

## 実行プロンプト

あなたはドメイン駆動設計の専門家です。以下の手順でドメインマッピングを実行してください。

### 前提条件

以下の中間ファイルが存在することを確認：
- `01_analysis/ubiquitous_language.md`
- `01_analysis/actors_roles_permissions.md`
- `01_analysis/domain_code_mapping.md`
- `01_analysis/current_system_overview.md`

### Step 1: ドメイン境界の特定

ユビキタス言語とコードマッピングを分析し、ドメイン境界を特定：

```
# 中間ファイルを読み込み
Read ubiquitous_language.md
Read domain_code_mapping.md
```

**識別のヒント：**
- 用語の意味が変わる境界
- 責務が明確に異なる領域
- 異なるライフサイクルを持つデータ
- 異なるビジネスルールが適用される領域

### Step 2: ドメインタイプの判定

各ドメインについて、ビジネス構造軸でタイプを判定：

#### Pipeline Domainの特徴
- [ ] 明確な入力と出力がある
- [ ] 処理の順序が重要
- [ ] データが変換されながら流れる
- [ ] 並列処理可能なステップがある

#### Blackboard Domainの特徴
- [ ] 共有リソースへの同時アクセス
- [ ] 競合状態の管理が必要
- [ ] 複数のエージェントが協調
- [ ] 状態の一貫性が重要

#### Dialogue Domainの特徴
- [ ] リアルタイムの双方向通信
- [ ] イベント駆動
- [ ] 非同期処理が中心
- [ ] セッション管理が必要

### Step 3: サービスカテゴリの判定

各ドメインについて、マイクロサービス境界軸でカテゴリを判定：

#### Process Domainの特徴
- [ ] 複数ステップのワークフロー
- [ ] トランザクション境界の管理
- [ ] 状態遷移の管理
- [ ] ビジネスルールの集約

#### Master/Reference Domainの特徴
- [ ] エンティティのCRUD操作
- [ ] データの正規化
- [ ] 参照整合性の維持
- [ ] マスタデータの提供

#### Integration Domainの特徴
- [ ] 外部APIとの連携
- [ ] プロトコル変換
- [ ] データフォーマット変換
- [ ] エラーハンドリング・リトライ

#### Supporting Domainの特徴
- [ ] 複数ドメインから利用される
- [ ] 技術的な横断関心事
- [ ] ビジネスロジックなし
- [ ] インフラ寄りの機能

### Step 4: 境界づけられたコンテキストの定義

**このステップ完了時に出力**: `reports/03_design/domain-analysis.md`

各ドメインについて以下を定義：

```markdown
## [コンテキスト名]

### 概要
[コンテキストの責務と目的]

### ユビキタス言語（このコンテキスト内）
| 用語 | 定義 | 他コンテキストとの違い |
|-----|------|---------------------|

### 含まれるエンティティ
- [エンティティ1]
- [エンティティ2]

### 提供する機能
- [機能1]
- [機能2]

### 依存するコンテキスト
- [コンテキストA]: [依存の内容]
- [コンテキストB]: [依存の内容]
```

### Step 5: コンテキストマップの作成

コンテキスト間の関係を以下のパターンで整理：

| パターン | 説明 | 使用場面 |
|---------|-----|---------|
| **Shared Kernel** | 共有モデル | 密接に連携するコンテキスト |
| **Customer-Supplier** | 上流-下流関係 | データ提供者と消費者 |
| **Conformist** | 下流が上流に従う | 変更不可能な外部システム |
| **Anti-corruption Layer** | 変換層を設ける | レガシーシステム連携 |
| **Open Host Service** | 公開APIを提供 | 複数消費者への提供 |
| **Published Language** | 共有の言語 | 標準プロトコル使用 |
| **Separate Ways** | 独立して動作 | 連携不要 |
| **Partnership** | 対等な協力関係 | 共同開発 |

**このステップ完了時に出力**:
- `reports/03_design/context-map.md` - コンテキストマップ（Mermaid図含む）
- `reports/03_design/system-mapping.md` - システム全体のマッピング

### Step 6: Mermaid図の検証

出力したファイルのMermaid図を検証し、エラーがあれば修正：

```bash
# 出力ファイルのMermaid検証
/fix-mermaid ./reports/03_design
```

**検証項目:**
- [ ] サブグラフ名が引用符で囲まれている
- [ ] 日本語ラベルが引用符で囲まれている
- [ ] エッジラベルの特殊文字（ハイフン等）が引用符で囲まれている
- [ ] ノードIDが英字で始まっている

## 出力フォーマット

### domain_analysis.md

ドメイン分析（ドメイン一覧、ドメインタイプ分類、サービスカテゴリ分類、境界づけられたコンテキスト、コンテキストマップ、課題と推奨事項）

### system_mapping.md

システムマッピング（現行システム→ドメインマッピング、トランザクション境界分析、データ移行計画、依存関係分析、移行準備度評価）

## ツール活用ガイドライン

### コード解析

```
# ドメインモデルの特定
mcp__serena__find_symbol で Entity/Aggregate を検索
mcp__serena__get_symbols_overview でクラス構造を把握

# 依存関係の分析
mcp__serena__find_referencing_symbols で参照を追跡
```

### 設計書からの抽出

```
# 設計書の読み取り
Read で設計書ファイルを読み込み
Grep でキーワード検索
```

## エラーハンドリング

- ドメイン境界が不明確な場合 → 暫定境界を設定し、要検証としてマーク
- 用語の定義が曖昧な場合 → ユーザーに確認を求める
- 循環依存が見つかった場合 → Anti-corruption Layer の導入を提案