bounded context とは？モデル間の境界線を引く

bounded context とは、特定の domain model が適用され、各用語が単一で曖昧さのない意味を持つ境界です。

domain-driven design の概念である bounded context は、繰り返し現れる問題への答えです。同じ言葉がビジネスの部分ごとに違う意味を持つという問題です。billing における「customer」は、support における「customer」と同じモデルではありません。bounded context は、各モデルがその内側で一貫を保つよう明示的な線を引きます。そしてその線は、しばしばまさにサービスとパイプラインを分ける場所です。

モデルを囲む境界

bounded context の内側では、domain model は内部的に一貫し、各用語が1つの意味を持ちます。context をまたぐと、同じ言葉が異なるモデルに対応しうります。context は、モデルとその言語が曖昧さを持たない範囲です。

なぜ重要か

すべてを意味しようとする1つの絡まったモデルを防ぐ。
ドメインの一貫したスライスの明確な所有権をチームに与える。
サービスを分割するための自然な継ぎ目を浮かび上がらせる。
モデル間の翻訳を、偶発的ではなく明示的にする。

境界がどこに落ちるか

bounded context はしばしば、チーム、サービス、deployment unit に対応します。よく選ばれた context の境界は、線を越えて必要な結合と翻訳を最小化するため、きれいなマイクロサービスの境界を形作る傾向があります。

context 間の翻訳

2つの context が対話する必要があるとき、それらは明示的な契約、API や event schema を通じて翻訳し、一方の context のモデルを他方へマッピングします。その翻訳層こそが、CI の contract テストが検証する API contract です。

CI/CD とのつながり

良い context の境界は、所有権・サービス・パイプラインを揃えます。変更は通常1つの context の内側にとどまるため、その build、テスト、deploy は1つのサービスに限定されます。悪い境界は、変更を多数のサービスとパイプラインへ一度に漏らします。

封じ込められた変更、封じ込められたビルド

変更が1つの bounded context の内側にとどまれば、その context のパイプラインだけが動き、フィードバックが高速に保たれます。ウォームなマネージド runner（Latchkey など）は、その限定されたビルドが共有キューで待つのではなく素早く返るようにします。

重要なポイント

bounded context とは、その中で domain model とその用語が一貫する範囲である。
その境界は、しばしばサービスと deployment unit の自然な線になる。
context 間の翻訳は、CI が検証できる明示的な契約である。