phasegate 0.15.0

package/skills/engineering-perspective/references/domain-model.md

@@ -0,0 +1,363 @@
+# ドメインモデル - エンジニアリング視点
+
+## 概要
+
+このドメインモデルは統合視点を中心に、ケント・ベック、マーティン・ファウラー、アンクル・ボブ、エリック・エヴァンスの思考パターン・視点・価値観を統合したものである。
+主な用途はAIエージェントにこれらの視点を持たせ、設計レビュー・要件整理・チーム議論などの場面で活用すること。
+
+## 統合モデル図
+
+```mermaid
+classDiagram
+    class EngineeringPerspective {
+        <<Aggregate Root>>
+        +IntegratorCore integrator
+        +KentBeckPrinciples kentBeck
+        +FowlerPatterns fowler
+        +UncleBobPrinciples uncleBob
+        +EvansDDD evans
+        +evaluate(input) EvaluationResult
+        +guide(problem) Guidance
+        +detectSmells(code) List~Smell~
+    }
+
+    class IntegratorCore {
+        <<Entity>>
+        +CoreValues values
+        +ThinkingFlow flow
+        +ExpressionPatterns patterns
+        +integrate(perspectives) Guidance
+    }
+
+    class CoreValues {
+        <<Value Object>>
+        +Practicality practicality
+        +Simplicity simplicity
+        +Accountability accountability
+    }
+
+    class ThinkingFlow {
+        <<Entity>>
+        +Premise premise
+        +Model model
+        +Decision decision
+        +Action action
+        +process() Action
+    }
+
+    class KentBeckPrinciples {
+        <<Value Object>>
+        +XPValues xpValues
+        +TDDCycle tddCycle
+        +SmallSteps smallSteps
+        +applyTDD() Guidance
+    }
+
+    class XPValues {
+        <<Value Object>>
+        +Communication communication
+        +Simplicity simplicity
+        +Feedback feedback
+        +Courage courage
+        +Respect respect
+    }
+
+    class TDDCycle {
+        <<Value Object>>
+        +Red red
+        +Green green
+        +Refactor refactor
+        +execute() TestResult
+    }
+
+    class FowlerPatterns {
+        <<Value Object>>
+        +CodeSmellDetector smellDetector
+        +RefactoringCatalog refactorings
+        +detectSmells(code) List~CodeSmell~
+        +suggestRefactoring(smell) Refactoring
+    }
+
+    class CodeSmell {
+        <<Value Object>>
+        +SmellName name
+        +Location location
+        +Severity severity
+    }
+
+    class Refactoring {
+        <<Value Object>>
+        +RefactoringName name
+        +Steps steps
+        +apply() Code
+    }
+
+    class UncleBobPrinciples {
+        <<Value Object>>
+        +SOLIDPrinciples solid
+        +CleanArchitecture architecture
+        +Professionalism professionalism
+        +evaluateDesign(design) SOLIDViolations
+    }
+
+    class SOLIDPrinciples {
+        <<Value Object>>
+        +SRP srp
+        +OCP ocp
+        +LSP lsp
+        +ISP isp
+        +DIP dip
+        +checkViolation(code) List~Violation~
+    }
+
+    class CleanArchitecture {
+        <<Value Object>>
+        +DomainLayer domain
+        +UseCaseLayer useCase
+        +AdapterLayer adapter
+        +validateDependencies() bool
+    }
+
+    class EvansDDD {
+        <<Value Object>>
+        +StrategicDesign strategic
+        +TacticalDesign tactical
+        +UbiquitousLanguage language
+        +analyzeModel(code) ModelAnalysis
+    }
+
+    class StrategicDesign {
+        <<Value Object>>
+        +BoundedContext context
+        +ContextMap map
+        +CoreDomain coreDomain
+        +identifyBoundaries() List~Boundary~
+    }
+
+    class TacticalDesign {
+        <<Value Object>>
+        +Aggregates aggregates
+        +Entities entities
+        +ValueObjects valueObjects
+        +DomainEvents events
+        +validateTactics() List~Issue~
+    }
+
+    class SmellDetector {
+        <<Domain Service>>
+        +fowlerSmells FowlerPatterns
+        +solidViolations UncleBobPrinciples
+        +dddSmells EvansDDD
+        +detectAll(code) List~Smell~
+    }
+
+    class EvaluationResult {
+        <<Value Object>>
+        +Verdict verdict
+        +List~SmellReport~ smells
+        +List~Suggestion~ suggestions
+        +overallScore Score
+    }
+
+    class Guidance {
+        <<Value Object>>
+        +String advice
+        +Perspective source
+        +List~Action~ actions
+        +Priority priority
+    }
+
+    EngineeringPerspective *-- IntegratorCore
+    EngineeringPerspective *-- KentBeckPrinciples
+    EngineeringPerspective *-- FowlerPatterns
+    EngineeringPerspective *-- UncleBobPrinciples
+    EngineeringPerspective *-- EvansDDD
+    EngineeringPerspective --> SmellDetector : uses
+    EngineeringPerspective ..> EvaluationResult : creates
+    EngineeringPerspective ..> Guidance : creates
+
+    IntegratorCore *-- CoreValues
+    IntegratorCore *-- ThinkingFlow
+
+    KentBeckPrinciples *-- XPValues
+    KentBeckPrinciples *-- TDDCycle
+
+    FowlerPatterns ..> CodeSmell : detects
+    FowlerPatterns ..> Refactoring : suggests
+
+    UncleBobPrinciples *-- SOLIDPrinciples
+    UncleBobPrinciples *-- CleanArchitecture
+
+    EvansDDD *-- StrategicDesign
+    EvansDDD *-- TacticalDesign
+
+    SmellDetector --> FowlerPatterns
+    SmellDetector --> UncleBobPrinciples
+    SmellDetector --> EvansDDD
+```
+
+## 各視点の役割
+
+### IntegratorCore（統合視点）
+
+全視点を統合し、実用的なガイダンスを生成する中心的役割。
+
+**責務:**
+- 前提確認から始まる思考フローの実行
+- 各視点からの情報を統合した判断
+- 状況に応じた表現パターンの選択
+
+### KentBeckPrinciples（XP・TDD視点）
+
+素早いフィードバックとシンプルさを重視。
+
+**適用場面:**
+- テスト戦略の検討
+- 開発プロセスの改善
+- 過剰設計の防止
+
+**キーフレーズ:**
+- "Make it work, make it right, make it fast"
+- "YAGNI - 今必要ないなら作らない"
+- "小さなステップで進む"
+
+### FowlerPatterns（リファクタリング視点）
+
+コードの匂いの検知と改善パターンの提案。
+
+**適用場面:**
+- コードレビュー
+- レガシーコードの改善
+- 設計パターンの適用
+
+**検知するコードスメル:**
+| スメル | 説明 | リファクタリング |
+|--------|------|------------------|
+| Long Method | 長すぎるメソッド | Extract Method |
+| Feature Envy | 他クラスのデータを多用 | Move Method |
+| Primitive Obsession | 基本型の過剰使用 | Replace with Value Object |
+| Shotgun Surgery | 変更が多クラスに影響 | Move Method/Field |
+| Divergent Change | 1クラスが複数理由で変更 | Extract Class |
+
+### UncleBobPrinciples（クリーン設計視点）
+
+SOLID原則とクリーンアーキテクチャの適用。
+
+**適用場面:**
+- アーキテクチャ設計
+- 依存関係の評価
+- インターフェース設計
+
+**SOLID原則チェック:**
+| 原則 | 違反の兆候 | 対処 |
+|------|------------|------|
+| SRP | 変更理由が複数 | クラス分割 |
+| OCP | 変更時に既存コード修正 | 抽象化・ポリモーフィズム |
+| LSP | 派生型で例外発生 | 継承の見直し |
+| ISP | 使わないメソッドへの依存 | インターフェース分割 |
+| DIP | 具象への依存 | 抽象への依存に変更 |
+
+### EvansDDD（ドメイン駆動視点）
+
+ドメインモデルの品質とユビキタス言語の整合性。
+
+**適用場面:**
+- ドメインモデリング
+- コンテキスト境界の設計
+- 集約設計
+
+**チェックポイント:**
+| 観点 | 確認事項 | 問題時の対処 |
+|------|----------|--------------|
+| ユビキタス言語 | コードと用語が一致 | 命名の統一 |
+| 境界づけられたコンテキスト | 責務が明確 | コンテキスト分割 |
+| 集約 | 整合性境界が適切 | 集約の再設計 |
+| ドメインイベント | 重要な出来事を表現 | イベント追加 |
+
+## 統合評価フロー
+
+```
+問題/コード
+    ↓
+┌─────────────────────────────────────────┐
+│  IntegratorCore: 前提確認               │
+│  - コンテキストは？                      │
+│  - 境界は？                              │
+│  - 目的は？                              │
+└─────────────────────────────────────────┘
+    ↓
+┌─────────────────────────────────────────┐
+│  並行評価                                │
+│  ├─ KentBeck: TDD/XP観点                │
+│  ├─ Fowler: コードスメル検知            │
+│  ├─ UncleBob: SOLID/アーキテクチャ      │
+│  └─ Evans: ドメインモデル品質           │
+└─────────────────────────────────────────┘
+    ↓
+┌─────────────────────────────────────────┐
+│  IntegratorCore: 統合・判断              │
+│  - 各視点の結果を統合                    │
+│  - 実用性を考慮してフィルタ              │
+│  - シンプルな改善案を選択                │
+└─────────────────────────────────────────┘
+    ↓
+EvaluationResult + Guidance
+```
+
+## ビジネスルール
+
+### 統合Good判定ルール
+
+以下をすべて満たす場合にGoodと判定：
+
+| 視点 | 基準 |
+|------|------|
+| 統合視点 | シンプル・説明可能・実用的 |
+| ケント・ベック | テストがある・YAGNIに従う |
+| ファウラー | コードスメルがない |
+| アンクル・ボブ | SOLID原則に従う・依存が内向き |
+| エヴァンス | ドメインを適切に表現・言語が一致 |
+
+### 統合NG判定ルール
+
+以下のいずれかに該当する場合にNGと判定：
+
+| 視点 | NG条件 |
+|------|--------|
+| 統合視点 | 複雑・目的不明・説明不能 |
+| ケント・ベック | テストなし・過剰設計 |
+| ファウラー | 重大なコードスメル |
+| アンクル・ボブ | SOLID違反・依存が外向き |
+| エヴァンス | モデル不一致・言語の乖離 |
+
+### 優先順位ルール
+
+改善提案の優先順位：
+
+1. **実用性に影響するもの** (統合視点)
+2. **テスト容易性に影響するもの** (ケント・ベック視点)
+3. **保守性に影響するもの** (ファウラー・アンクル・ボブ視点)
+4. **ドメイン表現に影響するもの** (エヴァンス視点)
+
+## 表現パターン（統合版）
+
+### 質問パターン
+
+| 視点 | パターン | 使用場面 |
+|------|----------|----------|
+| 統合視点 | 「前提は？」 | 議論開始時 |
+| 統合視点 | 「具体例にすると？」 | 抽象的な話のとき |
+| ケント・ベック | 「テストは書いた？」 | 実装レビュー時 |
+| ファウラー | 「これ匂う？」 | コードレビュー時 |
+| アンクル・ボブ | 「依存の方向は？」 | 設計レビュー時 |
+| エヴァンス | 「ドメインエキスパートはこう呼ぶ？」 | 命名議論時 |
+
+### 指摘パターン
+
+| 視点 | パターン | 使用場面 |
+|------|----------|----------|
+| 統合視点 | 「それって違くない？」 | スメル検知時 |
+| ケント・ベック | 「今必要ないなら作らない」 | 過剰設計時 |
+| ファウラー | 「リファクタしてから機能追加」 | 変更前 |
+| アンクル・ボブ | 「責務が複数ある」 | SRP違反時 |
+| エヴァンス | 「コンテキストが混ざってる」 | 境界不明確時 |

package/skills/engineering-perspective/references/glossary.md

@@ -0,0 +1,261 @@
+# ユビキタス言語 - エンジニアリング視点モデル用語集
+
+> ケント・ベック + マーティン・ファウラー + アンクル・ボブ + エリック・エヴァンスの視点を統合
+
+## コンテキスト: 統合思考パターン
+
+### 核心概念
+
+| 用語 | 定義 | 関連用語 | 備考 |
+|------|------|----------|------|
+| 実用性 | 理論より実際に使えることを優先する価値観 | シンプルさ, バーティカルスライス | 最優先の判断基準 |
+| シンプルさ | 複雑さを排除し本質だけを残すこと | 実用性, モデル化 | Good判定の主要基準 |
+| 説明責任 | なぜそうなのかを論理的に説明できること | 前提, 意思決定 | 設計判断の必須条件 |
+
+### 思考フロー関連
+
+| 用語 | 定義 | 関連用語 | 備考 |
+|------|------|----------|------|
+| 前提 | 問題を考える際にまず確認すべき条件・制約 | コンテキスト, 境界値 | 思考の起点 |
+| コンテキスト | どの文脈・状況での話かを明確にすること | 前提, 境界 | 前提確認の要素 |
+| 境界値 | どこまでが対象範囲かを定める区切り | コンテキスト, 前提 | 前提確認の要素 |
+| 目的 | 最終的に何を達成したいか | 意思決定, 行動 | 前提確認の要素 |
+| モデル化 | 複雑な事象を構造化して理解可能な形にすること | 抽象化, 具体化 | 統合視点の中核能力 |
+| 意思決定 | 前提と目的に基づき選択を行うこと | 前提, 行動 | 思考フローの中間 |
+| 行動 | 意思決定を実現するための具体的なアクション | 意思決定, バーティカルスライス | 思考フローの出力 |
+
+### 開発アプローチ
+
+| 用語 | 定義 | 関連用語 | 備考 |
+|------|------|----------|------|
+| バーティカルスライス | 機能を薄く縦に切り、最小限で価値提供すること | FBサイクル, 実用性 | 実装の入り込み防止 |
+| FBサイクル | フィードバックを得て改善を繰り返すプロセス | バーティカルスライス, 実用性 | 価値提供後の学習 |
+| TDD | テスト駆動開発。テストを先に書く開発手法 | テスト容易性, 変更容易性 | 設計品質の担保 |
+| DDD | ドメイン駆動設計。業務知識をコードで表現 | ドメイン表現, ドメインスメル | 設計思想の軸 |
+
+### 設計品質基準
+
+| 用語 | 定義 | 関連用語 | 備考 |
+|------|------|----------|------|
+| テスト容易性 | テストしやすい設計であること | TDD, 変更容易性 | Good判定の基準 |
+| 変更容易性 | 後から変更しやすい設計であること | テスト容易性, シンプルさ | Good判定の基準 |
+| ドメイン表現 | ビジネスロジックをコードで適切に表現すること | DDD, 値オブジェクト | Good判定の基準 |
+
+### ドメインスメル（検知対象）
+
+| 用語 | 定義 | 関連用語 | 備考 |
+|------|------|----------|------|
+| ドメインスメル | 設計上の問題を示す違和感・兆候 | 責務混在, 不適切な値オブジェクト | 統合視点の検知対象 |
+| 責務混在 | 一つのコンポーネントに複数の責務が混ざっている状態 | 集約, 分離 | NGパターン |
+| 不適切な値オブジェクト | nullableや条件付きフィールドを持つ値オブジェクト | ドメイン分解, 再設計 | NGパターン |
+
+### DDD基本要素
+
+| 用語 | 定義 | 関連用語 | 備考 |
+|------|------|----------|------|
+| 集約 | 一貫性を保つべきエンティティのまとまり | 集約ルート, エンティティ | DDDの重要概念 |
+| 集約ルート | 集約の入り口となるエンティティ。外部からは集約ルート経由でのみアクセス可能 | 集約, エンティティ | DDDの重要概念 |
+| エンティティ | 識別子（ID）によって同一性を判断するオブジェクト。ライフサイクルを持つ | 集約, 値オブジェクト | DDDの基本要素 |
+| 値オブジェクト | 属性の組み合わせで等価性を判断する不変オブジェクト | エンティティ, ドメイン表現 | DDDの基本要素 |
+| ドメインサービス | 特定のエンティティに属さないドメインロジックを表現するサービス | エンティティ, 値オブジェクト | DDDの基本要素 |
+
+### チーム・コミュニケーション
+
+| 用語 | 定義 | 関連用語 | 備考 |
+|------|------|----------|------|
+| 共通認識構築 | チームで理解を揃えること | ユビキタス言語, 議論 | コミュニケーションの軸 |
+| 抽象→具体 | 抽象的な概念を具体例で説明すること | モデル化, 伝達 | 説明スキル |
+| 具体→抽象 | 具体的な事例からパターンを抽出すること | モデル化, 理解 | 分析スキル |
+
+## コンテキスト: 表現パターン
+
+### 質問・確認パターン
+
+| パターン | 使用場面 | 目的 |
+|----------|----------|------|
+| 「前提は？」 | 議論の開始時 | 条件・制約を明確化 |
+| 「具体例にするとどうなりますか？」 | 抽象的な話のとき | 理解を深める |
+| 「それって違くない？」 | スメル検知時 | 問題の指摘 |
+| 「何をしたいの？」 | 目的が不明確なとき | 目的の明確化 |
+
+### 伝達構造パターン
+
+| パターン | 構造 | 使用場面 |
+|----------|------|----------|
+| 意思決定伝達 | 前提 → したい意思決定 → 意思決定のための行動 | 提案・報告時 |
+| 状況適応型 | 相手・場面に応じて構成を変える | 柔軟なコミュニケーション |
+
+---
+
+## コンテキスト: ケント・ベック視点
+
+> XP・TDDの創始者。シンプルさとフィードバックを重視。
+
+### 核心的価値観
+
+| 用語 | 定義 | 関連用語 | 備考 |
+|------|------|----------|------|
+| コミュニケーション | チーム内で知識を共有し続けること | フィードバック, ペアプロ | XP価値の1つ |
+| シンプリシティ | 今必要なことだけを行い、余計なことをしない | YAGNI, リファクタリング | XP価値の1つ |
+| フィードバック | 素早く頻繁に結果を得て学習すること | TDD, 継続的インテグレーション | XP価値の1つ |
+| 勇気 | 必要な変更を恐れずに行うこと | リファクタリング, 技術的負債 | XP価値の1つ |
+| リスペクト | チームメンバーを尊重すること | コミュニケーション, ペアプロ | XP価値の1つ |
+
+### 開発原則
+
+| 用語 | 定義 | 関連用語 | 備考 |
+|------|------|----------|------|
+| Red-Green-Refactor | テスト失敗→成功→改善のサイクル | TDD, リファクタリング | TDDの基本サイクル |
+| YAGNI | "You Ain't Gonna Need It" 今必要ないものは作らない | シンプリシティ, 過剰設計 | 過剰設計の防止 |
+| Make it work, make it right, make it fast | まず動かす→正しく→速くの順序 | TDD, リファクタリング | 最適化の順序 |
+| 小さなステップ | 大きな変更を小さな安全なステップに分解 | リファクタリング, 継続的インテグレーション | リスク軽減 |
+
+### 特徴的フレーズ
+
+| パターン | 使用場面 | 目的 |
+|----------|----------|------|
+| 「テストは先に書く」 | 実装開始時 | 設計を駆動する |
+| 「動くコードを書いてからリファクタ」 | 実装中 | 品質と速度の両立 |
+| 「今必要ないなら作らない」 | 機能追加の議論時 | 過剰設計の防止 |
+
+---
+
+## コンテキスト: マーティン・ファウラー視点
+
+> リファクタリングの第一人者。コードの匂いとアーキテクチャパターンの専門家。
+
+### 核心的価値観
+
+| 用語 | 定義 | 関連用語 | 備考 |
+|------|------|----------|------|
+| 読みやすさ | コードは書く時間より読む時間の方が長い | リファクタリング, 命名 | 最優先事項 |
+| 継続的改善 | 常にコードを少しずつ良くし続ける | リファクタリング, 技術的負債 | 品質維持の鍵 |
+| 明示的な設計 | 暗黙の設計判断を明示的にする | パターン, ドキュメント | 理解しやすさ |
+
+### コードスメル
+
+| 用語 | 定義 | 関連用語 | 備考 |
+|------|------|----------|------|
+| コードスメル | リファクタリングが必要な兆候 | リファクタリング, 技術的負債 | 問題の早期発見 |
+| Long Method | 長すぎるメソッド | Extract Method, 単一責任 | 代表的なスメル |
+| Feature Envy | 他のクラスのデータを多用する | Move Method, カプセル化 | 責務の配置ミス |
+| Primitive Obsession | 基本型の過剰使用 | 値オブジェクト, ドメイン表現 | ドメイン表現不足 |
+| Shotgun Surgery | 1つの変更が多くのクラスに影響 | 凝集度, モジュール化 | 設計の問題 |
+
+### リファクタリングパターン
+
+| 用語 | 定義 | 関連用語 | 備考 |
+|------|------|----------|------|
+| Extract Method | 長いメソッドから一部を抽出 | Long Method, 再利用 | 基本テクニック |
+| Move Method | メソッドを適切なクラスに移動 | Feature Envy, 責務 | 責務の再配置 |
+| Replace Conditional with Polymorphism | 条件分岐を多態性に置換 | OCP, 拡張性 | 設計改善 |
+| Introduce Parameter Object | 複数パラメータをオブジェクト化 | 値オブジェクト, 凝集度 | インターフェース改善 |
+
+### 特徴的フレーズ
+
+| パターン | 使用場面 | 目的 |
+|----------|----------|------|
+| 「コードの匂いがする」 | コードレビュー時 | 問題の指摘 |
+| 「リファクタリングしてから機能追加」 | 変更前 | 安全な変更 |
+| 「2回目で抽象化を検討」 | 重複発見時 | 早すぎる抽象化の防止 |
+
+---
+
+## コンテキスト: アンクル・ボブ視点
+
+> Clean Code/Architectureの提唱者。SOLID原則とプロフェッショナリズムを重視。
+
+### 核心的価値観
+
+| 用語 | 定義 | 関連用語 | 備考 |
+|------|------|----------|------|
+| プロフェッショナリズム | 職人としての誇りと責任 | クリーンコード, 品質 | 最重要価値 |
+| クリーンコード | 読みやすく、変更しやすく、テストしやすいコード | SOLID, リファクタリング | 目指すべき状態 |
+| 依存性の管理 | 依存の方向を制御し、変更の影響を局所化 | DIP, クリーンアーキテクチャ | 設計の核心 |
+
+### SOLID原則
+
+| 用語 | 定義 | 関連用語 | 備考 |
+|------|------|----------|------|
+| SRP | 単一責任原則。クラスを変更する理由は1つだけ | 凝集度, モジュール化 | Sの原則 |
+| OCP | 開放閉鎖原則。拡張に開き、修正に閉じる | ポリモーフィズム, 抽象化 | Oの原則 |
+| LSP | リスコフ置換原則。派生型は基底型と置換可能 | 継承, インターフェース | Lの原則 |
+| ISP | インターフェース分離原則。クライアント固有の小さなIF | 凝集度, 依存性 | Iの原則 |
+| DIP | 依存性逆転原則。上位が下位に依存しない | 抽象化, ポート | Dの原則 |
+
+### クリーンアーキテクチャ
+
+| 用語 | 定義 | 関連用語 | 備考 |
+|------|------|----------|------|
+| 同心円アーキテクチャ | 中心にドメイン、外側にインフラ | DIP, ポート&アダプター | 依存の方向は内向き |
+| ユースケース | アプリケーション固有のビジネスルール | ドメイン, コントローラ | 中間層 |
+| インターフェースアダプター | 外部とユースケースを繋ぐ変換層 | コントローラ, プレゼンター | 境界の役割 |
+| フレームワーク独立 | ビジネスロジックがFWに依存しない | DIP, テスト容易性 | 目指すべき状態 |
+
+### 特徴的フレーズ
+
+| パターン | 使用場面 | 目的 |
+|----------|----------|------|
+| 「ボーイスカウトルール」 | コード変更時 | 来た時より美しく |
+| 「関数は1つのことだけをせよ」 | 実装時 | 単一責任の適用 |
+| 「依存は内側に向ける」 | 設計時 | アーキテクチャの原則 |
+| 「テストがないコードはレガシーコード」 | レビュー時 | テストの重要性 |
+
+---
+
+## コンテキスト: エリック・エヴァンス視点
+
+> DDDの創始者。ドメインの本質的複雑さへのフォーカスとユビキタス言語を重視。
+
+### 核心的価値観
+
+| 用語 | 定義 | 関連用語 | 備考 |
+|------|------|----------|------|
+| ドメイン中心 | 技術ではなくビジネスドメインを中心に設計 | ユビキタス言語, モデル | 最重要価値 |
+| 継続的学習 | ドメインの理解は開発を通じて深まる | モデル駆動, イテレーション | 開発哲学 |
+| 戦略的設計 | 大きな構造と境界を先に設計 | 境界づけられたコンテキスト, コアドメイン | マクロ設計 |
+
+### 戦略的設計パターン
+
+| 用語 | 定義 | 関連用語 | 備考 |
+|------|------|----------|------|
+| 境界づけられたコンテキスト | 特定のモデルが適用される明示的な境界 | ユビキタス言語, コンテキストマップ | 最重要概念 |
+| コンテキストマップ | コンテキスト間の関係を示す図 | 統合パターン, 境界 | 全体像の把握 |
+| コアドメイン | 競争優位の源泉となる中心領域 | 汎用サブドメイン, 投資判断 | 注力すべき領域 |
+| 汎用サブドメイン | 差別化に寄与しない汎用的な領域 | コアドメイン, 既製品 | 投資を抑える領域 |
+
+### 戦術的設計パターン
+
+| 用語 | 定義 | 関連用語 | 備考 |
+|------|------|----------|------|
+| ユビキタス言語 | チーム全員が使う共通のドメイン用語 | 境界づけられたコンテキスト, モデル | コミュニケーションの基盤 |
+| モデル駆動設計 | コードがモデルを直接表現する | ドメインモデル, 実装 | 設計と実装の一致 |
+| 集約 | 一貫性境界を持つエンティティの集まり | 集約ルート, トランザクション | 整合性の単位 |
+| ドメインイベント | ドメインで起きた重要な出来事 | イベントソーシング, 結果整合性 | 疎結合の実現 |
+| 仕様パターン | ビジネスルールをオブジェクトとして表現 | 値オブジェクト, ルール | ルールの明示化 |
+
+### 特徴的フレーズ
+
+| パターン | 使用場面 | 目的 |
+|----------|----------|------|
+| 「モデルとコードを一致させる」 | 実装時 | モデル駆動設計 |
+| 「言葉を大切にする」 | 議論時 | ユビキタス言語の構築 |
+| 「コンテキストの境界を明確に」 | 設計時 | 責務の分離 |
+| 「本質的複雑さに立ち向かう」 | 設計判断時 | 偶発的複雑さの排除 |
+
+---
+
+## コンテキスト: 視点の統合
+
+統合視点は上記4名の視点を実践的に統合したメタ視点である。
+
+### 視点マッピング
+
+| 統合視点の特徴 | ケント・ベック | マーティン・ファウラー | アンクル・ボブ | エリック・エヴァンス |
+|----------------|----------------|------------------------|----------------|----------------------|
+| 前提確認 | フィードバック | - | - | ドメイン理解 |
+| シンプルさ重視 | シンプリシティ | 読みやすさ | クリーンコード | 本質的複雑さ |
+| ドメインスメル検知 | - | コードスメル | SOLID違反 | モデル不一致 |
+| バーティカルスライス | 小さなステップ | - | - | イテレーション |
+| モデル化能力 | - | パターン適用 | アーキテクチャ | ドメインモデル |
+| 共通認識構築 | コミュニケーション | - | - | ユビキタス言語 |