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

ECサイトの「商品」を考えよう。販売では商品名や価格、配送では重さやサイズ、サポートでは問い合わせ対象としての情報が必要だね。これは説明用の分け方だけど、全部を一つの意味やクラスに押し込めず、各範囲に合うモデルを一貫して使うのが大切なんだ。

たとえば販売の商品IDを配送へ渡すとき、配送側で何を意味するかを決めるよ。APIやメッセージで連携する場合も、項目の対応や変更時の扱いを明確にするんだ。同じ名前の項目だからと、同じ意味・同じモデルだと思い込まないようにしよう。

業務の担当者と話して、同じ言葉がどこで別の意味になるか、どのルールを一緒に扱う必要があるかを探るよ。チームの責任範囲やコードの使われ方も手がかりになる。部署の区切りをそのまま写すだけで、よい境界が決まるわけではないんだ。

必ずではないよ。これはモデルが通用する範囲の話で、プロセスやサーバーの数を決めるものではないんだ。一つのアプリに複数のコンテキストを置くこともある。サービスを分けるなら、独立した変更や運用の必要性、通信の負担も考えよう。

異なる意味を混ぜると、会話や実装に食い違いが生まれるよ。逆に細かく分けすぎると、対応づけや連携が複雑になる場合もあるね。業務への理解が深まったら、モデルの境界とその関係を見直すんだ。