IT 技書の森

境界づけられたコンテキスト

ドメインモデルが一貫した意味を持つ範囲を明確に区切り、モデルの曖昧さを排除する DDD の戦略的パターン

DDD設計パターン

境界づけられたコンテキストとは

境界づけられたコンテキスト (Bounded Context) は、ドメイン駆動設計 (DDD) の戦略的パターンで、特定のドメインモデルが一貫した意味を持つ範囲を明示的に定義する概念である。Eric Evans が「ドメイン駆動設計」で提唱した。

同じ「顧客」という言葉でも、営業部門では「見込み客を含む商談相手」、経理部門では「請求先の法人」、サポート部門では「問い合わせ元のユーザー」を意味する。1 つの巨大なモデルでこれらの意味を統一しようとすると、あらゆる属性を持つ肥大化した「顧客」クラスが生まれ、変更のたびに全部門に影響が波及する。

境界づけられたコンテキストは、この問題を「モデルの適用範囲を区切る」ことで解決する。営業コンテキスト、経理コンテキスト、サポートコンテキストそれぞれに独自の「顧客」モデルを持たせ、コンテキスト間の変換は明示的なマッピングで行う。

マイクロサービスとの関係

境界づけられたコンテキストは、マイクロサービスの分割単位の有力な指針となる。1 つのコンテキストを 1 つのサービスにマッピングすることで、サービスの責務が明確になり、チームの自律性が高まる。

ただし、1 対 1 の対応が常に最適とは限らない。小さなコンテキストは 1 つのサービスにまとめた方が運用コストが下がる場合もあるし、大きなコンテキストは複数のサービスに分割した方がよい場合もある。

コンテキストマップ

複数の境界づけられたコンテキスト間の関係を図示したものがコンテキストマップ (Context Map) である。コンテキスト間の統合パターンには以下のようなものがある。

  • 共有カーネル (Shared Kernel): 2 つのコンテキストが共通のモデルを共有する。変更時は両チームの合意が必要
  • 顧客/供給者 (Customer/Supplier): 上流のコンテキストが下流の要求に応じて API を提供する
  • 腐敗防止層 (Anti-Corruption Layer): 外部コンテキストのモデルが自コンテキストに侵食するのを防ぐ変換層
  • 公開ホストサービス (Open Host Service): 標準化されたプロトコルで外部にサービスを公開する

実務での境界の見つけ方

境界の発見にはイベントストーミング (Event Storming) が有効だ。ドメインエキスパートと開発者が付箋を使ってビジネスイベントを洗い出し、イベントのクラスタリングからコンテキストの境界を導き出す。

実務上の落とし穴として、技術的な都合 (データベースの共有、既存のテーブル構造) でコンテキストの境界を決めてしまうケースがある。境界はビジネスドメインの構造に基づいて決めるべきであり、技術的な制約は後から対処する。

Eric Evans の「ドメイン駆動設計」第 4 部で戦略的設計として体系的に解説されている。「実践ドメイン駆動設計」(Vaughn Vernon 著) ではコンテキストマップの具体的な実装パターンが詳しい。

コンテキストごとのモデル

コンテキスト 「商品」の意味
カタログ 名前、説明、画像
在庫 SKU、数量、倉庫
配送 重量、サイズ 
// カタログコンテキスト
type Product = { id: string; name: string; description: string };
// 在庫コンテキスト (同じ「商品」でもモデルが異なる)
type InventoryItem = { sku: string; quantity: number; warehouse: string };

境界づけられたコンテキストについては関連書籍でも詳しく扱われている。

関連用語