Ddd Redesign

DDD Redesign Agent

DDD評価結果に基づいて、システムの再設計計画を策定するエージェントです。

概要

このエージェントは以下を実行します：

1. 前提条件の検証 - 必要な入力ファイルの存在確認
2. 評価結果の統合 - DDD評価とMMI評価の結果を統合分析
3. ドメイン分類 - ビジネス構造軸とサービス境界軸での分類
4. 戦略的設計の改善 - 境界コンテキストの再定義、コンテキストマップの再設計
5. 戦術的設計の改善 - 集約、エンティティ、値オブジェクトの再設計
6. ユビキタス言語の整備 - 用語の統一と文書化
7. 移行計画の策定 - 段階的な移行ロードマップの作成

前提条件

必須入力ファイル

以下のファイルが存在すること：

• reports/02_evaluation/ddd-strategic-evaluation.md ← /ddd-evaluation で生成
• reports/02_evaluation/ddd-tactical-evaluation.md ← /ddd-evaluation で生成
• reports/02_evaluation/ddd-improvement-plan.md ← /ddd-evaluation で生成

推奨入力ファイル

以下のファイルが存在すれば参照：

• reports/01_analysis/ubiquitous-language.md ← /analyze-system で生成
• reports/01_analysis/domain-code-mapping.md ← /analyze-system で生成
• reports/02_evaluation/mmi-overview.md ← /evaluate-mmi で生成
• reports/02_evaluation/mmi-improvement-plan.md ← /evaluate-mmi で生成
• reports/02_evaluation/integrated-evaluation.md ← /integrate-evaluations で生成

出力先

結果は reports/03_design/ に出力します。 中間状態は work/{project}/design/ddd-redesign/ に記録します。 重要: 各ステップ完了時に即座にファイルを出力してください。

reports/03_design/
├── domain-analysis.md              # Step 3完了時（旧map-domainsの出力を統合）
├── bounded-contexts-redesign.md    # Step 4完了時
├── context-map.md                  # Step 5完了時（旧map-domainsの出力を統合）
├── aggregate-redesign.md           # Step 6完了時
├── ubiquitous-language-refined.md  # Step 7完了時
├── system-mapping.md               # Step 8完了時（旧map-domainsの出力を統合）
└── ddd-migration-roadmap.md        # Step 9完了時

work/{project}/design/ddd-redesign/
├── prerequisites-check.md          # 前提条件チェック結果
├── context-comparison.md           # 現行vs新設計の比較
├── aggregate-mapping.md            # 集約マッピング
└── redesign-progress.md            # 進捗状況

実行プロンプト

あなたはドメイン駆動設計（DDD）の再設計専門家エージェントです。以下の手順でDDD再設計を実行してください。

Step 0: 前提条件の検証

重要: 実行前に必ず前提条件を確認してください。

必須ファイルの確認:
├── reports/02_evaluation/ddd-strategic-evaluation.md  [必須]
├── reports/02_evaluation/ddd-tactical-evaluation.md   [必須]
├── reports/02_evaluation/ddd-improvement-plan.md      [必須]
└── 上記すべてが存在すること

推奨ファイルの確認:
├── reports/01_analysis/ubiquitous-language.md         [推奨]
├── reports/01_analysis/domain-code-mapping.md         [推奨]
├── reports/02_evaluation/mmi-overview.md              [推奨]
├── reports/02_evaluation/mmi-improvement-plan.md      [推奨]
└── reports/02_evaluation/integrated-evaluation.md     [推奨]

エラーハンドリング:

• 必須ファイルが存在しない場合:

  ⚠️ 前提条件エラー: 以下のファイルが見つかりません
  - reports/02_evaluation/ddd-strategic-evaluation.md
  
  推奨アクション:
  1. /ddd-evaluation を実行してください
  2. 必要なファイルが生成されてから再実行してください
  

• 推奨ファイルが存在しない場合 → 警告を出して続行

このステップ完了時に出力: work/{project}/design/ddd-redesign/prerequisites-check.md

Step 1: 評価結果の確認と統合

既存の評価結果を読み込み、課題を整理：

読み込み対象:
├── [必須] reports/02_evaluation/ddd-strategic-evaluation.md
├── [必須] reports/02_evaluation/ddd-tactical-evaluation.md
├── [必須] reports/02_evaluation/ddd-improvement-plan.md
├── [推奨] reports/02_evaluation/mmi-overview.md
├── [推奨] reports/02_evaluation/mmi-improvement-plan.md
└── [推奨] reports/01_analysis/ubiquitous-language.md

統合分析の観点:

1. DDD評価からの課題

   • 戦略的設計の問題（境界不明確、コンテキスト重複等）
   • 戦術的設計の問題（貧血モデル、集約過大等）

2. MMI評価からの課題（存在する場合）

   • 凝集度の低いモジュール → 境界コンテキスト再検討の候補
   • 結合度の高いモジュール → ACL導入の候補
   • 独立性の低いモジュール → サービス分離の候補

3. 課題の優先順位付け

   • Critical: システム全体に影響、即座に対応必要
   • High: 主要機能に影響、早期対応推奨
   • Medium: 一部機能に影響、計画的に対応
   • Low: 改善推奨だが影響は限定的

Step 2: ドメイン分類フレームワーク

各ドメインをビジネス構造軸とサービス境界軸で分類します。

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

2.2 サービス境界軸（Service Category）

Step 3: ドメイン分析

各ドメインの詳細分析を実施：

分析項目:
├── ドメイン名と概要
├── ビジネス構造タイプ（Pipeline/Blackboard/Dialogue/Hybrid）
├── サービスカテゴリ（Process/Master/Integration/Supporting）
├── Core/Supporting/Generic の分類
├── 主要なビジネスケイパビリティ
├── 含まれるエンティティ・集約
└── 他ドメインとの依存関係

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

Step 4: 境界コンテキストの再設計

4.1 コンテキスト分割の検討

分割基準:
├── ビジネスケイパビリティ
│   ├── 独立した価値提供単位
│   ├── ドメインエキスパートの責任範囲
│   └── ビジネスプロセスの境界
├── チーム構造（コンウェイの法則）
│   ├── 既存チーム境界
│   ├── 理想的なチーム構成
│   └── コミュニケーションパターン
├── 技術的制約
│   ├── データ整合性要件
│   ├── パフォーマンス要件
│   └── セキュリティ境界
├── 変更頻度
│   ├── 高頻度変更領域
│   ├── 安定領域
│   └── 規制対象領域
└── MMI評価結果（存在する場合）
    ├── 凝集度スコアの低いモジュール
    ├── 結合度スコアの高いモジュール
    └── 独立性スコアの低いモジュール

4.2 コンテキスト定義テンプレート

Context:
  name: "Sales Context"
  type: "Core Domain"
  domain_type: "Pipeline"           # ビジネス構造軸
  service_category: "Process"       # サービス境界軸
  description: "販売・受注に関するビジネスロジック"
  responsibilities:
    - 注文の受付と管理
    - 顧客との契約管理
    - 価格計算と見積もり
  ubiquitous_language:
    - Order: 顧客からの購入要求
    - Quote: 見積もり
    - Contract: 取引契約
  boundaries:
    includes:
      - order/
      - pricing/
      - contract/
    excludes:
      - inventory/
      - shipping/
  aggregates:
    - Order
    - Quote
    - Contract
  dependencies:
    upstream:
      - Inventory Context (Customer-Supplier)
    downstream:
      - Shipping Context (Published Language)
  mmi_metrics:  # MMI評価からの参照（存在する場合）
    cohesion: 75
    coupling: 60
    independence: 70

このステップ完了時に出力: reports/03_design/bounded-contexts-redesign.md

Step 5: コンテキストマップの再設計

5.1 コンテキスト間関係パターン

5.2 統合パターンの設計

統合方式の選択:
├── 同期（RPC/REST）
│   ├── 用途: 即時応答が必要
│   ├── 注意: 結合度が高くなる
│   └── ACL配置: 呼び出し側
├── 非同期（メッセージ/イベント）
│   ├── 用途: 疎結合、イベント駆動
│   ├── 注意: 結果整合性の考慮
│   └── 変換層: メッセージハンドラ
└── 共有データベース（推奨しない）
    ├── 用途: 移行過渡期のみ
    ├── 注意: 高結合、スキーマ変更困難
    └── 目標: 早期に分離

このステップ完了時に出力: reports/03_design/context-map.md

Step 6: 集約の再設計

6.1 集約設計の原則

設計原則:
├── 真の不変条件を保護
│   ├── ビジネスルールの特定
│   ├── トランザクション境界の明確化
│   └── 整合性要件の分析
├── 小さな集約を優先
│   ├── 1ルート + 少数のエンティティ/VO
│   ├── 参照はIDで行う
│   └── 結果整合性の活用
├── 集約間の参照
│   ├── IDによる参照のみ
│   ├── オブジェクト参照は避ける
│   └── 遅延ロードに注意
└── 集約ルートの責務
    ├── 不変条件の強制
    ├── 内部への唯一のアクセスポイント
    └── ライフサイクル管理

6.2 集約定義テンプレート

Aggregate:
  name: Order
  context: Sales Context
  root: Order
  entities:
    - OrderItem
  value_objects:
    - Money
    - OrderStatus
    - ShippingAddress
  invariants:
    - "注文合計は0より大きい"
    - "キャンセル済み注文は変更不可"
    - "注文項目は1つ以上必要"
  domain_events:
    - OrderPlaced
    - OrderConfirmed
    - OrderCancelled
  repository:
    interface: OrderRepository
    methods:
      - findById(OrderId): Order
      - save(Order): void
      - nextIdentity(): OrderId
  current_issues:  # DDD評価からの問題点
    - "OrderItemがルートから独立してアクセスされている"
    - "Moneyがプリミティブで表現されている"
  recommended_changes:
    - "OrderItemへのアクセスをOrderルート経由に変更"
    - "MoneyをValue Objectとして実装"

このステップ完了時に出力: reports/03_design/aggregate-redesign.md

Step 7: ユビキタス言語の整備

7.1 用語の統一

整備内容:
├── 用語定義の明確化
│   ├── 日本語名
│   ├── 英語名（コード上の名称）
│   ├── 定義
│   └── 使用例
├── コンテキスト別の用語
│   ├── 同じ用語の異なる意味
│   ├── コンテキスト固有の用語
│   └── 共通用語（Shared Kernel）
└── 禁止用語・非推奨用語
    ├── 曖昧な用語
    ├── 技術用語の混入
    └── 古い用語

このステップ完了時に出力: reports/03_design/ubiquitous-language-refined.md

Step 8: システムマッピング

現行システムから新設計へのマッピングを作成：

マッピング内容:
├── 現行モジュール → 新コンテキスト対応表
├── 現行テーブル → 新集約対応表
├── トランザクション境界の変更点
├── データ移行計画の概要
└── 依存関係の変更点

このステップ完了時に出力: reports/03_design/system-mapping.md

Step 9: 移行ロードマップの策定

9.1 フェーズ分割

Phase 0: 準備
├── チーム編成とトレーニング
├── 開発環境の整備
├── 既存コードの安定化
└── 監視・ログの強化

Phase 1: 基盤構築
├── 境界コンテキストの物理分離準備
├── 共通ライブラリの整備
├── ACL/変換層の実装
└── CI/CDパイプラインの整備

Phase 2: コア集約の再設計
├── 最重要集約から着手
├── リッチドメインモデルへの移行
├── 値オブジェクトの導入
└── 単体テストの充実

Phase 3: コンテキスト分離
├── サービス分離
├── データベース分離
├── イベント駆動の導入
└── 統合テストの充実

Phase 4: 最適化（継続的）
├── パフォーマンスチューニング
├── 監視・アラートの最適化
├── ドキュメント整備
└── チーム間プロセスの改善

9.2 リスク管理

リスク項目:
├── 技術的リスク
│   ├── データ移行の失敗
│   ├── パフォーマンス劣化
│   └── 統合テストの不足
├── 組織的リスク
│   ├── スキル不足
│   ├── チーム間コミュニケーション
│   └── ステークホルダーの理解
└── ビジネスリスク
    ├── 機能追加の遅延
    ├── 運用コストの増加
    └── 障害時の影響範囲

このステップ完了時に出力: reports/03_design/ddd-migration-roadmap.md

Step 10: Mermaid図の検証

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

/fix-mermaid ./reports/03_design

エラーハンドリング

関連スキル

注意事項

このスキルは以下の機能を統合しています：

• 旧 /map-domains のドメイン分類機能
• 旧 /map-domains のコンテキストマップ作成機能
• 旧 /map-domains のシステムマッピング機能

/map-domains は簡易版として残っていますが、完全なDDD再設計を行う場合はこの /ddd-redesign を使用してください。