ddd-bounded-context

1 行での概要

境界づけられたコンテキストとは、単一のモデルと、そのモデルに名前を付けるユビキタス言語に一貫性と完全性が保たれる明確な境界です。

このスキルを使う場面

• システムの異なる部分で、同じ名詞が別々の意味を持っています（営業の「顧客」とサポートの「顧客」など）。
• モデルが複雑に絡み合い、個々の変更が予期しない範囲に波及しています。
• チームの境界とコードの境界が一致していません。
• 「これを独立したサービスにすべきか」とチームで議論しています。

このスキルを使わない場面

• コンテキスト内のリファクタリング — 戦術的パターンのスキルに委ねてください。
• コンテキスト同士の関係についての質問 → ddd-context-mapping に案内してください。
• ビジネス全体でモデリングの労力をどう配分するか → ddd-subdomain-classification に案内してください。

主な内容

境界づけられたコンテキストは概念上のものであり、デプロイ単位に縛られるものではありません。モデルの一貫性が保たれる範囲を指します。モジュール、パッケージ、マイクロサービス、システム全体のいずれでも構いません。重要なのは、境界の内側では、すべての用語が一つの意味を持ち、すべてのルールに一貫性があることです。

境界が必要な兆候。

• システムの異なる部分で、同じ言葉が別々の意味を持っています。
• 実行されているコード領域によって、モデルの二つのルールが互いに矛盾しています。
• 「同じ」モデルへの変更をめぐり、二つのチームがたびたび互いの作業に干渉しています。
• あるユーザーグループ向けのUIは別のユーザーグループ向けのUIと大きく異なりますが、同じドメインコードを使用しています。

コンテキストとマイクロサービス。 境界づけられたコンテキストはモデルの境界であり、マイクロサービスはデプロイの境界です。両者は一致することが多いものの、必ずしも一致する必要はありません。一つのサービスが二つのコンテキストをホストすることもあります（モジュール境界によって明確に分離します）。二つのサービスが同じコンテキストを実装することもあります（まれで、通常は誤りです）。

境界の命名。 各コンテキストには、ビジネス上の目的を反映した名前を付けてください。営業、請求、配送、IDなどです。技術的な名前（バックエンド、コア）は避けてください。ドメインの専門家が理解できる名前にしてください。

判断のヒューリスティクス

• プロジェクトの初期段階では、少数の大きなコンテキストを優先してください。分割は簡単ですが、統合にはコストがかかります。
• 用語をどうしても統一できない場合、チームに自律性が必要な場合、またはモデルのルールが矛盾する場合に分割してください。
• マイクロサービスごとに境界づけられたコンテキストを一つ割り当てるべきだと決めつけないでください。対応関係はモデルによって決まり、デプロイのトポロジーによって決まるものではありません。

アンチパターン

• データベースのテーブルごとに境界づけられたコンテキストを宣言する — 形だけで、実際にはモデルの境界が引かれていません。
• モデルが破綻するまで境界を無視する — その時点では、整理が大規模なプロジェクトになっています。
• 「境界づけられたコンテキスト」を「マイクロサービス」の同義語として扱う。
• 内部のユビキタス言語に名前を付けずに境界を引く。

関連項目

• ddd-ubiquitous-language — 境界の内側にあるもの。
• ddd-context-mapping — コンテキスト同士の関係。
• ddd-subdomain-classification — どのコンテキストに最も労力をかけるべきか。

参考資料

• Evans, Domain-Driven Design（2003年）、第14章（モデルの整合性の維持）。