DDDに関して、境界付きコンテキストとは何ですか？

Vaughn Vernon著の「Implementing Domain Driven Design」という本を読んでいると、境界のあるコンテキストが実際に何であるかをよく理解できませんでした。

この本は、境界付きコンテキストを「ドメインモデルが適用可能な概念的境界。チームによって話され、慎重に設計されたソフトウェアモデルで表現されるユビキタス言語を提供します」と定義します。この定義は、境界コンテキストがサブドメインのモデルと言語であるかのように聞こえます。そのサブドメインは、たまたまコアドメイン（「コアサブドメイン」と呼ばれるべきですが、それは別の議論...）。これは、境界付きコンテキストが提供するものに関して、まだいくつかのあいまいさを残しています。1つ以上のサブドメインのグループ化ですか？1つのサブドメインのみが境界付きコンテキストに対応している場合、境界付きコンテキストは実際に何を伝えていますか？

ただし、同じ本の第3章では、境界のあるコンテキスト間の統合手法について言及しています。ただし、これは、境界付けられたコンテキストが実際にはソフトウェアシステムまたはさまざまなアーティファクトであることを意味するように思われます。

Martin Fowlerは、境界のあるコンテキスト（http://martinfowler.com/bliki/BoundedContext.html）のアイデアについて簡単に説明しますが、実際には問題を明確にしません。

一日の終わりには、何である有界コンテキストは？サブドメインのグループ化ですか？サブドメインのモデルと言語？サブドメインの実装？これらの答えがなければ、現実の問題空間を境界のあるコンテキストに分解する方法を理解するのはかなり難しいようです。

境界付けられたコンテキストとサブドメインは異なるレベルに存在します。

A サブドメインは、それがだ、問題空間の部分である天然の分割しばしば組織の構造を反映し、システム。したがって、ロジスティクスと運用は、請求と請求から分離される可能性があります。Eric は、特定のシナリオでのビジネス関連性に従って、コアサブドメイン、サポートサブドメイン、および汎用サブドメインを区別します。

コンテキストは、ソリューション空間の一部です。彼らはモデルです。ドメインとサブドメインのパーティション分割を反映させておくのは良いことですが、人生は必ずしもそれほど簡単ではありません。そして、すべてを網羅するレガシードメイン、または同じサブドメイン内のより多くのコンテキスト（つまり、誰かが構築している古いレガシーアプリと代替アプリ）を含む肥大化したレガシードメインがあるかもしれません。

持っているために有界コンテキストを、あなたは、モデル、およびその周辺の明示的な境界を持っている必要があります。データベースを使用してデータを共有する多くのデータ駆動型アプリケーションに欠けているもの。

別の-直交-それを見る方法は次のようになります。ユビキタス言語、すべての用語に単一の明確な定義がある特別な条件は、スケールしません。拡大すればするほど、あいまいさが入り込みます。正確で明確なモデルを実現するには、明確な目的で、境界を明確にし、それぞれが単一の境界コンテキスト内にある多くの小さなユビキタス言語を話す必要があります。 。

ドメインドリブンデザインの手法は、私たちが住んでいる世界のモデルを作成するために使用されます。これらのモデルは、プロジェクトに携わる人々の心の中のアイデアとして存在します。

テレパシーはまだ初期段階にあるため、これらのアイデアは言葉やフレーズを使用して人々の間で伝えられます。

単語やフレーズは、よくてもあいまいになることがあります。あいまいさを減らすために、「コンテキスト」を使用してそれらの意味を明確にします。

人々が長年にわたるソフトウェアプロジェクトに深く没頭すると、コードに焼き付けられた変数名に変わる単語に変わるアイデアが生まれた背景を忘れているようです。

初心者がプロジェクトに到着し、その言語の使用と使用を開始します。おそらく彼らはユーザーであり、おそらく開発者です。彼らに文脈が提供されない場合、彼らは彼ら自身の人生経験から彼ら自身の文脈（したがって、意味）を思いつきます。

この新しく適用されたコンテキストは、新しい開発者がコードをリファクタリングまたは開発する方法をガイドします。間違ったコンテキストを適用した場合、彼らはコードをリファクタリングし、おそらくわずかに間違った方向に開発します。わずかな方向であっても、間違った方向は将来、さらに大きな問題を引き起こす可能性があります。

私が見るように、「バウンドコンテキスト」は、プロジェクトの初心者に渡される「明確なコンテキスト」にすぎないため、美しく研ぎ澄まされたモデルを汚すために独自の任意のコンテキストを適用することはありません。

チームが明示的に認めているのthis phraseは、this part of the projectという意味ですthis thing（あなたが思うかもしれませんが、そうではありませんthat thing）。

ちょうどあなたの庭とあなたの隣人の庭の間の境界をマークすることは良い考えです。手入れの行き届いた芝生で花壇を掘り始めたときに怒らないように、境界を明示的に指定します。

それだ。それは非常に重要な非常に単純なアイデアであり、多くのことが書かれています。

あ、はい。境界付きコンテキストは、文字通り、プロジェクト内のあるサブドメインのコンテキストと別のサブドメインのコンテキストを区別する境界、つまり「フェンス」です。

サブドメインのモデルと言語は、意味のあいまいさを避けるために、他のモデルと言語から分離されています。

でも、はい。世界はそれほど単純ではありません。

あなたとチームは、定義されたコンテキストを厳守する必要があります。怠け者であり、ソフトウェアの構築中にコーナーをカットするためにコンテキストを再想像するのは本当に簡単です。

また、物事は他の物事と相互作用し、境界のあるコンテキストも相互作用する必要があります。そのため、これらの相互作用がどのように発生するかを説明するさまざまなパターンがあります。これらのさまざまなパターンについては、エリック・エヴァンの本「ドメイン駆動設計」の第14章を参照してください：共有カーネル、顧客サプライヤー、コンフォーマスト、腐敗防止レイヤー、個別の方法、オープンホストサービス、公開言語。

基本的に、境界付きコンテキストは、サブドメインの適用可能性の具体的な境界を定義します。特定のサブドメインが理にかなっているのに対し、他のサブドメインは理にかなっていない抽象的な領域です。そのため、これはトーク、プレゼンテーション、アーティファクトによって定義された物理的境界を持つコードプロジェクトになります。

さまざまな状況で、私は3つの異なる視点、またはバウンドコンテキスト概念の比metaを使用します。

実行時の観点からは、モデルが実装されるサービスの契約によって定義される論理境界を表します。コントラクトは、このサービスのAPIまたは公開および消費する一連のイベントとして表すことができます。したがって、この観点から、境界付きコンテキストは物理的な境界とは関係ありません。

ドメインエキスパートの観点から見ると、境界コンテキストは、特定のビジネスプロセスが実装され、特定のユビキタス言語が適用され、特定の用語が明確な意味を持ち、他の用語はそうではない領域です。つまり、紙やホワイトボードに描かれた長方形にすぎません。

ソフトウェア開発者、つまり静的コードの観点から見ると、境界付きコンテキストは、対応するサブドメインを中心にモデルを設計した方法を表します。特定のサブドメインが実装されているコードベースはいくつありますか？それらはどのような概念で構成されていますか？どのコンセプトがそれぞれに適用可能ですか？そのため、境界付きコンテキストはソリューション空間に属していると言われています。

このバウンドコンテキストの概念の例が本当に気に入っています。

もう1つの重要な質問（最も重要でない場合）は、境界のあるコンテキストを識別する方法です。誤ってこれを行うと、おしゃべりで保守不能で密結合されたサービス（分散モノリスとも呼ばれます）になります。