境界づけられたコンテキストとは
公式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つの観点から解説が必要でしょう。
・概念としての境界づけられたコンテキスト
・境界づけられたコンテキストをどう実装に落としこむか
今回の記事では、概念の方の説明をしたいと思います。
概念としての境界づけられたコンテキスト
モデルの共有
こちらの記事で書いた通り、ドメイン駆動設計ではすべての人(ソフトウェア開発者、ドメインエキスパート)が同じ意味で言葉を使うことを目指します。
例えば、ECサイトで商品を販売するシステムを考えてみましょう。ここでは、エンジニアと販売管理する人たちの中で、「商品」に関しては同じモデルを共有します。
エンジニアと販売部のコミュニケーションがうまくいき、「商品」について同じモデル、言葉を共有することができました。
では、販売から配送までをシステム管理したくなったとします。
おっと、配送部の人は「商品」と言った時に全く別のものをイメージすることがわかりました！
ドメイン駆動設計ではすべての人が同じ意味で言葉を使うことを目指すのではなかったのでしょうか？
それでは強引に、「商品」の概念を統一しましょう。
『「商品」は売値、在庫数、配送先、配送状況を持ちます』・・・？
なにやらややこしくなってきました。さらに、ドメイン駆動設計ではこれをコードに落とし込むことを目指すので、「商品」の振る舞いを「商品」クラスに詰め込んでいくことに・・・上手くいくイメージが湧きますか？
さらに、請求の管理までをシステム化することになり、カウンターパートとして経理部の人も増えました。当然、経理の人は「商品」に関して違うイメージを持っています。
さて、すべての人が同じ意味で言葉を使うことを目指す・・・ことは可能でしょうか？
そう、システムが大規模になると、関係者すべてで統一したモデルを作ることは難しくなるのです。
エリック・エヴァンスのドメイン駆動設計
In those younger days we were advised to build a unified model of the entire business, but ドメイン駆動設計 recognizes that we've learned that "total unification of the domain model for a large system will not be feasible or cost-effective"
昔はビジネス全体の統一モデルを構築するようにアドバイスされていたが、ドメイン駆動設計は、「大規模システムのドメインモデルの完全な統合は実現不可能で、費用対効果が低い」と認識しています
そこで、ドメイン駆動設計では大きなシステムを「境界づけられたコンテキスト」に分割し、それぞれの中でモデル、言語の統一を目指すのです。
境界づけられたコンテキストによる分割
コンテキストを分割することができました！「販売コンテキスト」「配送コンテキスト」それぞれが一つの「境界づけられたコンテキスト」になります。
それぞれのコンテキスト内では、関係者の中で「商品」は必ず同じモデル、用語で統一します。この範囲でなら、モデル、用語を統一することは現実的になりそうですね。
コンテキストマッピング
さて、販売と配送を別のコンテキストとして定義し、「商品」を別のモデルにしましたが、現実的には「商品」は繋がっています。
ということは、このコンテキストをまたいで「商品」をどう扱うかを決めないといけません。
このようなコンテキスト同士の関係性を簡単な図で表すことを、コンテキストマッピングと言います。
このように
1.モデリング対象を境界づけられたコンテキストで分割する
2.コンテキスト同士の関係をマッピングする
という手順を踏むことが、ドメイン駆動設計の第一歩です。
なぜなら、ドメイン駆動設計では、「ドメイン専門家とソフトウェア専門家のコラボレーションでモデルを探求する」ことを目指しますが、「モデル」はまず適用するコンテキストを区切らないと定義できないからです。
境界づけられたコンテキストの実装
さて、ここまでで概念はおわかりいただけたと思います。
ただ、「言いたいことはわかった、でも結局どうやって実装するのか全然わからないよ」という状況ですよね？
次の記事ではその実装について書きたいと思います。お楽しみに！
(2017/12/7追記 続編を書きました)
もっと詳しく知りたい方は
初めてDDDを学ぶ方、もしくは実際に着手して難しさにぶつかっている方向けの書籍を出しました。
迷子になりがちな「DDDの目的」や「モデル」の解説からはじめ、
具体的なモデリングを行い実装まで落とす事例を元に、DDDの魅力や効果を体感することを目指します。
よろしければお求めください。
また、実践にあたって頻出の疑問に対してトピックごとに詳しく解説した書籍もあります。
重要トピック「モデリング」「集約」「テスト」について詳細に解説し、その他のトピックでは頻出の質問への回答と具体的なサンプルコードをふんだんに盛り込みました。現場で実践して、困っていることがある方はぜひこちらもご覧ください。
現場での導入で困ったら
DDDを導入しようとすると結構試行錯誤に時間がかかります。
現場で導入してすぐに効果を発揮したい！！という方向けに、基礎解説とライブモデリング/コーディングを行う勉強会の開催や、設計相談を受付ております。
事例紹介もあるのでご関心あれば覗いてみてください。開催形式は柔軟に対応できるのでお気軽にご相談ください。
Twitterでも、DDDに関して発信したり、「質問箱」というサービスを通じて質問を受け付けています。こちらもよろしければフォローしてください。
https://twitter.com/little_hand_s
また、YouTubeで10分でわかるDDD動画シリーズをアップしています。概要を動画で理解したい方はこちらもどうぞ。チャンネル登録すると新しい動画の通知を受け取ることができます。
