Menu
DDD評価エージェント - 戦略的設計・戦術的設計の両面からDDD原則への適合度を評価し改善点を特定。/ddd-evaluation [対象パス] で呼び出し。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
ScalarDB Analytics設計エージェント - ScalarDB Analyticsを使用した分析基盤の設計。Apache Sparkベースの分析クエリ、マルチDB横断分析を策定。/design-scalardb-analytics [対象パス] で呼び出し。
ScalarDBサイジング見積もりエージェント - Enterprise/OSSエディション別のインフラ構成・Pod数・コストを対話形式で見積もり。/scalardb-sizing-estimator で呼び出し。
システム分析エージェント - ユビキタス言語、アクター、ロール、権限、ドメイン-コード対応表を抽出。/analyze-system [対象パス] で呼び出し。
GraphDB構築エージェント - ユビキタス言語とコード解析結果からRyuGraphデータベースを構築。/build-graph [対象パス] で呼び出し。
ドメインストーリーテリングエージェント - ドメインストーリーの作成、ビジネスプロセスの可視化。/create-domain-story --domain=[ドメイン名] で呼び出し。
API設計エージェント - リファクタリング後のマイクロサービスAPI設計。REST/GraphQL/gRPC/AsyncAPIの仕様書、API Gateway設計、認証・認可設計を策定。/design-api [対象パス] で呼び出し。
| name | ddd-evaluation |
| description | DDD評価エージェント - 戦略的設計・戦術的設計の両面からDDD原則への適合度を評価し改善点を特定。/ddd-evaluation [対象パス] で呼び出し。 |
| user_invocable | true |
ドメイン駆動設計（DDD）の視点から既存システムを評価し、改善点を特定するエージェントです。
このエージェントは以下を実行します：
reports/01_analysis/ubiquitous-language.md ← /analyze-system で生成reports/before/{project}/ddd-readiness.md ← /system-investigation で生成結果は reports/02_evaluation/ に出力します。
中間状態は work/{project}/investigation/ddd-evaluation/ に記録します。
重要: 各ステップ完了時に即座にファイルを出力してください。
reports/02_evaluation/
├── ddd-strategic-evaluation.md # Step 1完了時
├── ddd-tactical-evaluation.md # Step 2完了時
├── ddd-pattern-analysis.md # Step 3完了時
└── ddd-improvement-plan.md # Step 4完了時
work/{project}/investigation/ddd-evaluation/
├── context-candidates.md # コンテキスト候補
├── aggregate-candidates.md # 集約候補
└── evaluation-progress.md # 進捗状況
あなたはドメイン駆動設計（DDD）の専門家エージェントです。以下の手順でDDD評価を実行してください。
重要: 実行前に必ず前提条件を確認してください。
推奨ファイルの確認:
├── reports/01_analysis/ubiquitous-language.md [推奨] ← /analyze-system
├── reports/01_analysis/domain-code-mapping.md [推奨] ← /analyze-system
└── reports/before/{project}/ddd-readiness.md [推奨] ← /system-investigation
必須:
└── 対象コードベースへのアクセス [必須]
エラーハンドリング:
1.1 境界コンテキストの分析
評価項目:
├── コンテキスト境界の明確さ
│ ├── モジュール/パッケージによる分離
│ ├── 名前空間による分離
│ └── 責務の分離度
├── コンテキスト間の関係
│ ├── 依存の方向性
│ ├── 共有カーネルの有無
│ └── 腐敗防止層の有無
└── コンテキストの独立性
├── デプロイ独立性
├── データ独立性
└── チーム独立性
1.2 ユビキタス言語の分析
評価項目:
├── 用語の一貫性
│ ├── コード内での命名
│ ├── コメント/ドキュメント
│ └── テストケース名
├── ドメインエキスパートとの整合性
│ ├── ビジネス用語の使用
│ ├── 技術用語の混入度
│ └── 略語の使用状況
└── コンテキスト間での用語の分離
├── 同一用語の異なる意味
├── ポリセミ（多義語）の検出
└── コンテキスト固有の語彙
1.3 コンテキストマップの分析
関係パターンの検出:
├── Partnership（協力関係）
├── Shared Kernel（共有カーネル）
├── Customer-Supplier（顧客-供給者）
├── Conformist（順応者）
├── Anti-Corruption Layer（腐敗防止層）
├── Open Host Service（公開ホストサービス）
├── Published Language（公表された言語）
└── Separate Ways（別々の道）
このステップ完了時に出力: reports/02_evaluation/ddd-strategic-evaluation.md
2.1 エンティティの分析
評価項目:
├── 識別子の設計
│ ├── ID生成戦略
│ ├── 自然キー vs サロゲートキー
│ └── ID型の適切さ
├── ライフサイクル管理
│ ├── 生成パターン
│ ├── 状態遷移
│ └── 不変条件
└── 振る舞いの充実度
├── ビジネスロジックの配置
├── 貧血ドメインモデルの検出
└── Tell, Don't Askの適用
2.2 値オブジェクトの分析
評価項目:
├── 不変性の確保
│ ├── イミュータブル設計
│ ├── 副作用のない操作
│ └── コンストラクタでの検証
├── 等価性の実装
│ ├── equals/hashCode
│ ├── 構造的同一性
│ └── 型安全性
└── 値オブジェクト候補の検出
├── プリミティブ執着の検出
├── 複合値の検出
└── 型エイリアスの検出
2.3 集約の分析
評価項目:
├── 集約ルートの特定
│ ├── ルートの責務
│ ├── 不変条件の保護
│ └── トランザクション境界
├── 集約サイズの適切さ
│ ├── 小さすぎる集約
│ ├── 大きすぎる集約
│ └── 参照vs値の判断
└── 集約間の参照
├── IDによる参照
├── オブジェクト参照の回避
└── 整合性境界
2.4 リポジトリの分析
評価項目:
├── インターフェース設計
│ ├── コレクション指向 vs 永続化指向
│ ├── クエリメソッドの設計
│ └── 仕様パターンの適用
├── 実装の品質
│ ├── インフラ層への分離
│ ├── テスト容易性
│ └── トランザクション管理
└── 集約単位の永続化
├── 集約全体の保存
├── 遅延ロード戦略
└── キャッシュ戦略
2.5 ドメインサービスの分析
評価項目:
├── サービスの責務
│ ├── ステートレス性
│ ├── ドメインロジックの配置
│ └── 複数集約の協調
├── サービスの粒度
│ ├── 単一責任
│ ├── インターフェースの明確さ
│ └── 依存の最小化
└── アプリケーションサービスとの区別
├── ユースケース層との分離
├── トランザクション管理
└── セキュリティ/認可
このステップ完了時に出力: reports/02_evaluation/ddd-tactical-evaluation.md
検出対象パターン:
戦術的パターン:
├── Factory（ファクトリ）
├── Repository（リポジトリ）
├── Domain Event（ドメインイベント）
├── Domain Service（ドメインサービス）
├── Application Service（アプリケーションサービス）
├── Specification（仕様）
└── Policy（ポリシー）
アーキテクチャパターン:
├── Layered Architecture（レイヤードアーキテクチャ）
├── Hexagonal Architecture（ヘキサゴナルアーキテクチャ）
├── Clean Architecture（クリーンアーキテクチャ）
├── CQRS
└── Event Sourcing
このステップ完了時に出力: reports/02_evaluation/ddd-pattern-analysis.md
分析結果に基づいて改善計画を策定：
改善計画の構造:
├── 短期改善（1-2週間）
│ ├── クイックウィン
│ ├── 命名の統一
│ └── 明らかな問題の修正
├── 中期改善（1-3ヶ月）
│ ├── 集約の再設計
│ ├── コンテキスト境界の明確化
│ └── リポジトリの改善
└── 長期改善（3ヶ月以上）
├── アーキテクチャ変更
├── コンテキスト分割
└── イベント駆動化
このステップ完了時に出力: reports/02_evaluation/ddd-improvement-plan.md
出力したファイルのMermaid図を検証し、エラーがあれば修正：
/fix-mermaid ./reports/02_evaluation
スコアは .claude/rules/evaluation-frameworks.md の「2. DDD評価フレームワーク」に定義された計算式に従って算出する。
総合DDDスコア:
DDD Score = Strategic × 0.30 + Tactical × 0.45 + Architecture × 0.25
各カテゴリの算出:
Strategic = UbiquitousLanguage × 0.33 + BoundedContext × 0.34 + SubdomainClassification × 0.33
Tactical = ValueObject × 0.20 + Entity × 0.20 + Aggregate × 0.20 + Repository × 0.15 + DomainService × 0.10 + DomainEvent × 0.15
Architecture = LayerSeparation × 0.40 + DependencyDirection × 0.35 + PortsAndAdapters × 0.25
各サブ項目: 0-100で採点（詳細基準は evaluation-frameworks.md §2.3 参照）
成熟度グレード: A(80-100), B(70-79), C(60-69), D(50-59), E(0-49)
# DDD戦略的設計評価
## 評価サマリー
| 評価項目 | スコア | グレード |
|---------|--------|---------|
| ユビキタス言語 | [0-100] | [A-E] |
| 境界コンテキスト | [0-100] | [A-E] |
| サブドメイン分類 | [0-100] | [A-E] |
| **戦略的設計スコア** | **[加重平均]** | **[A-E]** |
## 境界コンテキスト分析
### 検出されたコンテキスト
\`\`\`mermaid
graph TD
subgraph "Sales Context"
Order
Customer
end
subgraph "Inventory Context"
Product
Stock
end
subgraph "Shipping Context"
Shipment
Delivery
end
Order --> Product
Shipment --> Order
\`\`\`
### コンテキスト評価
| コンテキスト | 境界明確度 | 独立性 | 課題 |
|-------------|-----------|--------|------|
| Sales | 70% | Medium | 在庫への直接依存 |
| Inventory | 80% | High | - |
| Shipping | 50% | Low | 複数コンテキストへ依存 |
## ユビキタス言語分析
### 用語の一貫性
| 用語 | 使用箇所 | 一貫性 | 問題点 |
|-----|---------|--------|--------|
| Order | 15ファイル | 90% | 一部で「注文」と混在 |
| User/Customer | 20ファイル | 40% | 用語が統一されていない |
## コンテキストマップ
\`\`\`mermaid
graph LR
Sales -->|Customer-Supplier| Inventory
Sales -->|Partnership| Payment
Shipping -->|Conformist| Sales
Notification -->|ACL| Sales
\`\`\`
# DDD戦術的設計評価
## 評価サマリー
| 要素 | 検出数 | スコア (0-100) | 重み | 加重スコア | グレード |
|-----|--------|:-------------:|:----:|:---------:|:-------:|
| 値オブジェクト | [N] | [X] | 20% | [X×0.20] | [A-E] |
| エンティティ | [N] | [X] | 20% | [X×0.20] | [A-E] |
| 集約 | [N] | [X] | 20% | [X×0.20] | [A-E] |
| リポジトリ | [N] | [X] | 15% | [X×0.15] | [A-E] |
| ドメインサービス | [N] | [X] | 10% | [X×0.10] | [A-E] |
| ドメインイベント | [N] | [X] | 15% | [X×0.15] | [A-E] |
| **戦術的設計スコア** | | | | **[合計]** | **[A-E]** |
## エンティティ分析
### 検出されたエンティティ
| エンティティ | 場所 | ID設計 | 振る舞い | 評価 |
|-------------|------|--------|---------|------|
| User | domain/user.ts | UUID | 貧血 | C |
| Order | domain/order.ts | 連番 | リッチ | B |
| Product | domain/product.ts | SKU | 貧血 | C |
### 貧血ドメインモデルの検出
- `User` - 15個のgetter/setterのみ、ビジネスロジックなし
- `Product` - 価格計算がサービス層に漏出
## 値オブジェクト分析
### 値オブジェクト候補
| 候補 | 現在の実装 | 推奨 |
|-----|-----------|------|
| Email | string | EmailValueObject |
| Money | number | MoneyValueObject |
| Address | 複数フィールド | AddressValueObject |
## 集約分析
### 集約ルート一覧
| 集約ルート | メンバー | サイズ評価 | 問題点 |
|-----------|---------|-----------|--------|
| Order | OrderItem, Payment | 適切 | - |
| User | Profile, Settings, Orders | 大きすぎ | Ordersを分離推奨 |
# エンティティの検出
mcp__serena__search_for_pattern(substring_pattern="@Entity|class.*Entity", restrict_search_to_code_files=true)
# リポジトリの検出
mcp__serena__find_symbol(name_path_pattern="Repository", substring_matching=true, depth=1)
# 集約ルートの検出
mcp__serena__search_for_pattern(substring_pattern="@AggregateRoot|AggregateRoot", restrict_search_to_code_files=true)
# ドメインイベントの検出
mcp__serena__search_for_pattern(substring_pattern="DomainEvent|Event$", restrict_search_to_code_files=true)
| スキル | 用途 |
|---|---|
/system-investigation | 事前調査（DDD適合性の初期評価） |
/analyze-system | ユビキタス言語の詳細抽出 |
/ddd-redesign | 評価結果に基づく再設計計画 |
/map-domains | 境界コンテキストの詳細設計 |