境界付けられたコンテキストとは
公式DDD Referenceの定義は以下の通りです。(和訳はだいぶ意訳しています)
bounded context
A description of a boundary (typically a subsystem, or the work of a particular team) within which a particular model is defined and applicable.
境界付けられたコンテキスト
特定のモデルを定義・適用する境界を明示的に示したもの。
代表的な境界の例は、サブシステムやチームなど。
まぁなかなかよくわからないですよね。DDD用語の中でもかなり難解なワードです。
境界付けられたコンテキストは、2つの観点から解説が必要でしょう。
・概念としての境界付けられたコンテキスト
・境界付けられたコンテキストをどう実装に落としこむか
今回の記事では、概念の方の説明をしたいと思います。
概念としての境界付けられたコンテキスト
モデルの共有
ドメイン駆動設計の定義についてEric Evansはなんと言っているのか
こちらの記事で書いた通り、DDDではすべての人(ソフトウェア開発者、ドメインエキスパート)が同じ意味で言葉を使うことを目指します。
例えば、ECサイトで商品を販売するシステムを考えてみましょう。ここでは、エンジニアと販売管理する人たちの中で、「商品」に関しては同じモデルを共有します。
エンジニアと販売部のコミュニケーションがうまくいき、「商品」について同じモデル、言葉を共有することができました。
では、販売から配送までをシステム管理したくなったとします。
おっと、配送部の人は「商品」と言った時に全く別のものをイメージすることがわかりました！
DDDではすべての人が同じ意味で言葉を使うことを目指すのではなかったのでしょうか？
それでは強引に、「商品」の概念を統一しましょう。
『「商品」は売値、在庫数、配送先、配送状況を持ちます』・・・？
なにやらややこしくなってきました。さらに、DDDではこれをコードに落とし込むことを目指すので、「商品」の振る舞いを「商品」クラスに詰め込んでいくことに・・・上手くいくイメージが湧きますか？
さらに、請求の管理までをシステム化することになり、カウンターパートとして経理部の人も増えました。当然、経理の人は「商品」に関して違うイメージを持っています。
さて、すべての人が同じ意味で言葉を使うことを目指す・・・ことは可能でしょうか？
そう、システムが大規模になると、関係者すべてで統一したモデルを作ることは難しくなるのです。
エリック・エヴァンスのドメイン駆動設計
In those younger days we were advised to build a unified model of the entire business, but DDD recognizes that we've learned that "total unification of the domain model for a large system will not be feasible or cost-effective"
昔はビジネス全体の統一モデルを構築するようにアドバイスされていたが、DDDは、「大規模システムのドメインモデルの完全な統合は実現不可能で、費用対効果が低い」と認識しています
そこで、DDDでは大きなシステムを「境界付けられたコンテキスト」に分割し、それぞれの中でモデル、言語の統一を目指すのです。
境界付けられたコンテキストによる分割
コンテキストを分割することができました！「販売コンテキスト」「配送コンテキスト」それぞれが一つの「境界付けられたコンテキスト」になります。
それぞれのコンテキスト内では、関係者の中で「商品」は必ず同じモデル、用語で統一します。この範囲でなら、モデル、用語を統一することは現実的になりそうですね。
コンテキストマッピング
さて、販売と配送を別のコンテキストとして定義し、「商品」を別のモデルにしましたが、現実的には「商品」は繋がっています。
ということは、このコンテキストをまたいで「商品」をどう扱うかを決めないといけません。
このようなコンテキスト同士の関係性を簡単な図で表すことを、コンテキストマッピングと言います。
このように
1.モデリング対象を境界付けられたコンテキストで分割する
2.コンテキスト同士の関係をマッピングする
という手順を踏むことが、DDDの第一歩です。
なぜなら、DDDでは、「ドメイン専門家とソフトウェア専門家のコラボレーションでモデルを探求する」ことを目指しますが、「モデル」はまず適用するコンテキストを区切らないと定義できないからです。
境界付けられたコンテキストの実装
さて、ここまでで概念はおわかりいただけたと思います。
ただ、「言いたいことはわかった、でも結局どうやって実装するのか全然わからないよ」という状況ですよね？
次の記事ではその実装について書きたいと思います。お楽しみに！
【2021/10/30新刊】
DDD解説書の新刊を執筆しました。
重要トピック「モデリング」「集約」「テスト」について詳細に解説し、その他のトピックでは頻出の質問への回答と具体的なサンプルコードをふんだんに盛り込みました。現場で実践して、困っていることがある方はぜひこちらもご覧ください。
また、YouTubeで10分でわかるDDD動画シリーズをアップしています。概要を動画で理解したい方はこちらもどうぞ。チャンネル登録すると新しい動画の通知を受け取ることができます
DDD連載記事
なぜDDD初心者はググリ出してすぐに心がくじけてしまうのか
ドメイン駆動設計の定義についてEric Evansはなんと言っているのか
モデルでドメイン知識を表現するとは何か
ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か
ドメイン駆動 + オニオンアーキテクチャ概略
モデルとは"現実世界を正しく表現したもの"ではないという話
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話