DDDに関して、境界コンテキストとは何ですか？
Vaughn Vernon著の「Implementing Domain Driven Design」を読んでいるとき、境界コンテキストが実際に何であるかを十分に理解できませんでした。
この本は、境界ドメインを「ドメインモデルが適用される概念的な境界です。チームによって話され、慎重に設計されたソフトウェアモデルで表現されるユビキタス言語を提供します」と定義しています（「本の手引き」の冒頭のセクション）。この定義は、境界のあるコンテキストがサブドメインのモデルと言語であるかのように聞こえます。サブドメインはたまたまコアドメインである可能性があります（これは「コアサブドメイン」と呼ばれるべきであるように見えますが、それは別の議論...）これにより、制限付きコンテキストが提供するものについては、あいまいさが残ります。 1つ以上のサブドメインのグループですか？境界コンテキストに対応するサブドメインが1つだけの場合、境界コンテキストは実際に何を伝えているのですか？
ただし、同じ本の第3章では、境界コンテキスト間の統合手法について言及しています。ただし、これは、制限されたコンテキストが実際にはソフトウェアシステムまたはいくつかの種類のアーティファクトであることを示唆しているようです。
マーティンファウラーは、境界のあるコンテキスト（ http://martinfowler.com/bliki/BoundedContext.html ）のアイデアについて簡単に説明していますが、実際には問題を明確にしていません。
結局のところ、境界付きコンテキストとはとは何ですか？サブドメインのグループですか？サブドメインのモデルと言語は？サブドメインの実装？これらの答えがなければ、現実の問題の空間を制限されたコンテキストに分解する方法を理解するのはかなり難しいようです。
境界付きコンテキストとサブドメインは異なるレベルに存在します。
Subdomainは問題空間の一部であり、システムの自然なパーティション分割であることが多く、組織の構造を反映しています。したがって、logisticsおよびoperationsはinvoicing＆billingから分離される可能性があります。 Ericは、core、supportingおよびgenericサブドメインを、ビジネス上の関連性に従って区別します与えられたシナリオ。
Contextsはソリューション空間の一部です。彼らはモデルです。ドメインとサブドメインのパーティショニングを反映させておくのは良いことですが、人生は必ずしもそれほど簡単ではありません。そして、すべてを網羅するレガシードメイン、または同じサブドメイン内のより多くのコンテキスト（つまり、古いレガシーアプリが誰かが構築している代替アプリ）を肥大化させている可能性があります。
Bounded Contextを使用するには、モデルとその周囲の明示的な境界が必要です。データベースを使用してデータを共有する多くのデータ駆動型アプリケーションに欠けているものは何ですか。
別の-直交-それを見る方法は次のようになるかもしれません。 ユビキタス言語、すべての用語に明確な定義が1つあるという特別な条件は、スケーリングしません。拡大するほど、あいまいさが入り込みます。正確で明確なモデルを実現するには、それらの境界を明示し、明確に定義された目的で、それぞれが単一の境界コンテキスト内にある多くの小さなユビキタス言語を話す必要があります。 。
ドメインドリブンデザインテクニックは、私たちが住んでいる世界のモデルを作成するために使用されます。これらのモデルは、プロジェクトに携わる人々の心の中のアイデアとして存在します。
テレパシーはまだ始まったばかりなので、これらのアイデアは言葉やフレーズを使って人々の間で伝えられます。
言葉やフレーズは、多くの場合あいまいな場合があります。あいまいさを減らすために、「コンテキスト」を使用してそれらの意味を明確にします。
人々が何年にもわたるソフトウェアプロジェクトに深く没頭すると、コードに組み込まれた変数名に変わる単語に変わったアイデアの由来となったコンテキストを忘れてしまうようです。
初心者はプロジェクトに到着し、その言語の使用と消費を開始します。おそらくそれらはユーザーであり、おそらく開発者です。彼らに提供された文脈がない場合、彼らは彼ら自身の人生経験から彼ら自身の文脈（したがって、意味）を思い付くでしょう。
この新しく適用されたコンテキストは、新しい開発者がコードをリファクタリングまたは開発する方法をガイドします。彼らが間違ったコンテキストを適用した場合、彼らはコードをリファクタリングし、おそらく少しでも間違った方向にコードを開発します。誤った方向は、たとえわずかであっても、将来的にははるかに大きな問題を引き起こす可能性があります。
私が見ているように、「境界付きコンテキスト」は、初心者を投影するために渡される「明確なコンテキスト」にすぎないため、彼らは私たちの美しく磨かれたモデルを汚すために独自の任意のコンテキストを適用しません。
this phraseのthis part of the projectが正確にthis thingを意味することは、チームによる明確な承認です（そして、ご想像のとおり、that thingではありません）。
ちょうどあなたの庭とあなたの隣人の庭の間の境界をマークするのが良い考えであるように。完全に手入れされた芝生の上で花壇を掘り始めたときに怒らないように、境界を明示的に指定します。
それだ。それは非常に重要な非常に単純なアイデアであり、たくさんのことが書かれています。
あ、はい。境界付きコンテキストは、文字通り、プロジェクト内の1つのサブドメインのコンテキストと別のサブドメインのコンテキストを区別する境界、つまり「フェンス」です。
サブドメインのモデルと言語は、意味のあいまいさを避けるために、他のモデルと言語から分離されています。
でも、はい。世界はそれほど単純ではありません。
あなたとチームは、定義されたコンテキストを厳守する必要があります。ソフトウェアの構築中に手抜きをするコンテキストを再考し、怠惰になるのは本当に簡単です。
また、物事は他の物事と相互作用し、境界のあるコンテキストも互いに相互作用する必要があります。したがって、それらの相互作用がどのように発生するかを説明するためのさまざまなパターンがあります。これらのさまざまなパターンについては、Eric Evanの著書「ドメイン駆動設計」の第14章を参照してください。共有カーネル、顧客サプライヤー、適合者、腐敗防止レイヤー、個別の方法、オープンホストサービス、公開言語。
基本的に、境界付きコンテキストは、いくつかのサブドメインの適用可能性の具体的な境界を定義します。これは、特定のサブドメインには意味があるが、他のサブドメインには意味がない抽象的な領域です。したがって、これはトーク、プレゼンテーション、アーティファクトによって定義される物理的な境界を持つコードプロジェクトになる可能性があります。
さまざまな状況で、私は3つの異なる視点、つまり境界コンテキストの概念のメタファーを使用します。
ランタイムの観点からは、モデルが実装されているサービスのコントラクトによって定義される論理的な境界を表します。コントラクトは、このサービスのAPIまたはそれが発行および消費する一連のイベントとして表すことができます。したがって、この観点から、境界付きコンテキストは物理的な境界とは何の関係もありません。
ドメインエキスパートの観点から見ると、境界付きコンテキストとは、特定のビジネスプロセスが実装され、特定のユビキタス言語が適用され、特定の用語が明確であるのに対し、他の用語はそうではない領域です。つまり、紙やホワイトボードに描かれた長方形だけです。
ソフトウェア開発者にとって、つまり静的コードの観点から見ると、境界コンテキストは、対応するサブドメインを中心にモデルを設計した方法を表しています。特定のサブドメインが実装されているコードベースはいくつですか？それらはどのような概念で構成されていますか？それぞれに適用できる概念はどれですか？そのため、境界コンテキストはソリューション空間に属していると言われています。
私は本当に this 境界コンテキストの概念の例が好きです。
別の重要な質問（最も重要でない場合）は 境界付きコンテキストを識別する方法 です。これを誤って行うと、最終的には chatty、unmaintainable and密結合サービス （ distributed monolith とも呼ばれる）になります。