🔲
境界づけられたコンテキスト
ドメインモデルが一貫した意味を持つ明示的な境界。コンテキスト内ではユビキタス言語が統一される
定義
境界づけられたコンテキスト(Bounded Context)とは、特定のドメインモデルが適用される明示的な境界。境界の内部では:
- ユビキタス言語が一貫して使われる
- 「顧客」「注文」「商品」などの概念が一つの意味しか持たない
- チームが共同でモデルの責任を持つ
境界の外では同じ言葉が異なる意味を持つことがある。例えば「顧客」は販売コンテキストでは「購入者」、サポートコンテキストでは「チケットを上げる人」を意味しうる。
なぜ重要か
単一の巨大なドメインモデルを全システムで共有しようとすると:
- モデルが膨大な概念を抱え込み、理解不能になる
- チーム間の変更が互いに影響し合い、リリースが困難になる
- 用語の意味が文脈によって揺れ、コミュニケーションコストが増大する
Bounded Contextを明示的に設けることで、各チームが自律的にモデルを進化させられる。
適用場面
- システムを「どこで何を管理するか」で分割する設計議論
- マイクロサービスの境界を決める際(1コンテキスト≒1サービスが目安)
- 他チームとの統合方法を決める(コンテキストマップを描く)
- レガシーシステムのどこまでをリファクタリングの対象とするか(境界を引く)
注意点
Bounded ContextとSubdomainは1対1に対応しないことがある。1つのSubdomainに複数のContextが存在したり、複数のSubdomainが1つのContextに収まることもある。まずドメインを概念的に分析し(Subdomain)、次に実装の境界を引く(Bounded Context)。
出典
実践ドメイン駆動設計(Vaughn Vernon)第2章
- 1. 📐業務ロジックはドメインオブジェクトに書く
- 2. 🏷️区分オブジェクト
- 3. 🧩ドメインオブジェクトへの業務ロジック集約
- 4. 🔒不正な状態を型で表現不可能にする
- 5. 📦ファーストクラスコレクション(コレクションオブジェクト)
- 6. 🔌薄いサービス層パターン(Application Service)
- 7. 🏗️三層分離パターン(ドメイン・アプリケーション・インフラストラクチャ)
- 8. 🎯設計はドメインモデルから始める
- 9. 🗺️ドメインモデル抽出スキル
- 10. 🔨段階的リファクタリング戦略
- 11. 🎯型駆動設計(Type-Driven Design)
- 12. 💎値オブジェクト(Value Object)
- 13. ⚠️プリミティブ執着(Primitive Obsession)
- 14. 🚫状態フラグ・汎用テーブルのアンチパターン
- 15. 🎯DDDはなぜ必要か
- 16. 🗣️ユビキタス言語
- 17. 🔲境界づけられたコンテキスト