Referenceの定義は以下の通りです。applicable.境界付けられたコンテキスト特定のモデルを定義・適用する境界を明示的に示したもの。代表的な境界の例は、サブシステムやチームなど。DDD用語の中でもかなり難解なワードです。境界付けられたコンテキストは、2つの観点から解説が必要でしょう。・概念としての境界付けられたコンテキスト・境界付けられたコンテキストをどう実装に落としこむか今回の記事では、概念の方の説明をしたいと思います。Evansはなんと言っているのかこちらの記事で書いた通り、DDDではすべての人(ソフトウェア開発者、ドメインエキスパート)が同じ意味で言葉を使うことを目指します。ECサイトで商品を販売するシステムを考えてみましょう。ここでは、エンジニアと販売管理する人たちの中で、「商品」に関しては同じモデルを共有します。エンジニアと販売部のコミュニケーションがうまくいき、「商品」について同じモデル、言葉を共有することができました。販売から配送までをシステム管理したくなったとします。おっと、配送部の人は「商品」と言った時に全く別のものをイメージすることがわかりました!DDDではすべての人が同じ意味で言葉を使うことを目指すのではなかったのでしょうか?それでは強引に、「商品」の概念を統一しましょう。持ちます』・・・?なにやらややこしくなってきました。DDDではこれをコードに落とし込むことを目指すので、「商品」の振る舞いを「商品」クラスに詰め込んでいくことに・・・上手くいくイメージが湧きますか?さらに、請求の管理までをシステム化することになり、カウンターパートとして経理部の人も増えました。経理の人は「商品」に関して違うイメージを持っています。すべての人が同じ意味で言葉を使うことを目指す・・・ことは可能でしょうか?そう、システムが大規模になると、関係者すべてで統一したモデルを作ることは難しくなるのです。以下のようなことが語られています。cost-effective"昔はビジネス全体の統一モデルを構築するようにアドバイスされていたが、DDDは、「大規模システムのドメインモデルの完全な統合は実現不可能で、費用対効果が低い」と認識していますそこで、DDDでは大きなシステムを「境界付けられたコンテキスト」に分割し、それぞれの中でモデル、言語の統一を目指すのです。境界付けられたコンテキストによる分割コンテキストを分割することができました!「販売コンテキスト」「配送コンテキスト」それぞれが一つの「境界付けられたコンテキスト」になります。それぞれのコンテキスト内では、関係者の中で「商品」は必ず同じモデル、用語で統一します。この範囲でなら、モデル、用語を統一することは現実的になりそうですね。コンテキストマッピングさて、販売と配送を別のコンテキストとして定義し、「商品」を別のモデルにしましたが、現実的には「商品」は繋がっています。いうことは、このコンテキストをまたいで「商品」をどう扱うかを決めないといけません。このようなコンテキスト同士の関係性を簡単な図で表すことを、コンテキストマッピングと言います。このように1.モデリング対象を境界付けられたコンテキストで分割する2.コンテキスト同士の関係をマッピングするという手順を踏むことが、DDDの第一歩です。DDDでは、「ドメイン専門家とソフトウェア専門家のコラボレーションでモデルを探求する」ことを目指しますが、「モデル」はまず適用するコンテキストを区切らないと定義できないからです。境界付けられたコンテキストの実装さて、ここまでで概念はおわかりいただけたと思います。「言いたいことはわかった、でも結局どうやって実装するのか全然わからないよ」という状況ですよね?次の記事ではその実装について書きたいと思います。お楽しみに!【2021/10/30新刊】DDD解説書の新刊を執筆しました。重要トピック「モデリング」「集約」「テスト」について詳細に解説し、その他のトピックでは頻出の質問への回答と具体的なサンプルコードをふんだんに盛り込みました。現場で実践して、困っていることがある方はぜひこちらもご覧ください。YouTubeで10分でわかるDDD動画シリーズをアップしています。概要を動画で理解したい方はこちらもどうぞ。