境界付きコンテキストの境界を明確に定義する方法

1か月ほどDDDを読んで調査した後、私は自分のプロジェクトを開始することを決め、これらの制限されたコンテキストでDDDを作成しました>

• クライアント
• 製品
• 注文
• 課金

各境界付きコンテキストには、プレゼンテーション層、ドメイン層、永続層としてREST APIがあります。

これまでのところ、コードはスムーズに実行されていますが、モノリシックな世界から来ているので、私はまだ次のことを理解しようとしています：

• 新しいクライアントを作成したい場合、新しい請求書を発行したい場合、たとえば、国のアクセスリストなど、新しい注文を作成したい場合。私は：

a）各BCの国のリストを作成する

b）国BC-> APIを作成し、それを使用して利用可能な国のリストを取得する

c）サードパーティのAPIを使用し、各BCの腐敗防止層を介してデータをプルする

• 破損防止レイヤーまたはアダプターレイヤーを使用してサードパーティAPIと統合する場合、ドメインモデルにどのデータを含める必要がありますか？たとえば、zendesk APIをクライアントBCと統合したい場合。ドメインにticketIDのみが必要ですか、それともクライアントBCでアクセスして使用するすべてのデータをZendeskから抽出する必要がありますか？

MVCアプリが実際にAPI（境界コンテキストのプレゼンテーションレイヤー）からデータを取得している場合、各BCの境界を明確に定義することは非常に困難です。それは、適切に設計されたBCが、追加のAPIを消費する必要なしに単一のMVCコントローラーを提供することを意味しますか？

異なる境界のコンテキストが国の意味/目的を異なる方法で理解している場合は、国ごとに適切にモデル化する必要があります。ただし、ISOコードと名前の参照データについてだけ言えば、都合の良い場所に隠してすべての関係者がアクセスできるようにするのはかなり公平で標準的だと思います。たとえば、データベース、構成ファイル、Webサービスなどです。

私もあなたのモデルを少し見たかったです。あなたがリストしたものは、会社の構造に応じて、1つの「境界のあるコンテキスト」の「エンティティ」である可能性が非常に高くなります。BCはしばしば「ユビキタス言語」間の自然な境界であることが多いため、さまざまな領域/部門/チームを中心に定義されることになります。したがって、たとえば、Sales / Products / Ordersの代わりに、BCがSales / Manufacturing / Warehousingのラインに沿っていることを期待します。

それらの紀元前では、名詞に焦点を当てていません。ユースケースに焦点を当て、ユースケースを満たすことができる名詞のモデルを作成します。「集約ルート」のメソッドは、ユースケースを実行し、関連するモデルに適切な変更を加えます。

...すべてのモデルが間違っていますが、一部は有用です。

また、各BCはまったく異なるシステムまたはアーキテクチャを使用する可能性があることにも留意してください。特定のBCは「DDDソフトウェアコンポーネント」を使用するメリットがまったくない場合があり、それらのほとんどはおそらくそうではありません。DDDは、規範的なソフトウェアコンポーネントについてではなく、ソフトウェアの設計プロセスについてです。ポイントは、会社の境界のあるコンテキストの理解、各コンテキストのユビキタス言語のマッピング、およびユビキタス言語を使用したそのコンテキストのコードのモデリングに焦点を当てることです。そうすれば、利害関係者とやり取りしてコードを参照するときに、彼らが理解しているビジネス用語で話しているように聞こえます。そして、同じ言葉が異なるBCで異なる意味を持つことを認識する。

DDDによってもたらされる特定のパターン（たとえば、リポジトリ、特定のレイヤーなど）は、目的を達成するためのものです。ただし、これらのパターンは、DDD内であっても、すべての場合に最適なパターンであるとは限りません。DDDがすべてのプロジェクトの「その」答えであるのと同じように。あなたはあなたの分析が示唆することをしなければならないだけで、最も実践的なことです。

あなたの質問から、あなたは限られた文脈を誤解していると思います。ブルーブックの第14章をもう一度読んでください。

一般的に答えようとする-2つの異なる境界コンテキスト間で概念を共有することに注意する必要があります。結局、境界が存在する理由の一部は、ユビキタス言語が変化するためです。エンティティの同じデータ（および同じ表現）を両方のコンテキストで使用できると仮定するのは簡単ではありません-正しいかもしれませんが、間違っているかもしれませんが、外部にいる私たちにとって、アクセス権のない良い方法はありませんあなたのドメインの専門家に、裁判官に。

たとえば、クライアントドメインでは、「国」は居住または市民権に関連している可能性があります。請求では、為替レートに関連している可能性があります。それらのドメインのいくつかでは、関税などについて心配する必要があるかもしれません。

提起する必要がある2番目の質問は、どのモデルが「共有」データの記録簿であるかです。「国」の場合、正しい答えはおそらくどれもないということです！地政学的トポロジーはモデルによって制御されません。

国が外国勢力に占領されている場合、ドメインモデルで何が起こるはずですか？

覚えておいてください。私たちの多くは、データ構造について考えることに慣れています。あるデータと別のデータの関係は何ですか。また、レポートを検討していて、必要なすべてのデータがソリューションによって収集されていることを確認しようとしている場合は、これは素晴らしいことです。しかし、ドメインモデルは構造だけではなく、変化についてのものです。その部分にも注意を向ける必要があります。また、データが変更をどのように制約するか（また、これらの制約が境界コンテキストごとにどのように異なるか）を十分に理解していることを確認してください。

あなたが言及する概念（クライアント、製品、注文、請求）は、通常、単一のドメインモデルで表現されるため、境界コンテキストで表現されます。これらの概念を正しく理解していないことをお勧めします。

この主題についての私の見方は、ビジネス機能マッピングまたはバリューチェーン分析のような他の同様の手法を使用して、境界のあるコンテキストを定義することです。それは次のステップに帰着します：

1. システムのより高いレベルの責任またはビジネス機能を定義します。それを行うための最良の方法は、企業がビジネス価値を獲得するために実行するステップを思い起こさせることです。考えられる論理的な境界は、ビジネスサービス、または必要に応じて境界コンテキストです。
2. 各サービスの詳細を調べます。
3. 最初の2つのポイントとともに、サービス間の通信を特定します。

したがって、最初の焦点は、ビジネスの運用方法です。

いくつかの実用的なアドバイス：

1. コンテキスト/サービス/その他の1つが他のコンテキストのデータを必要とする場合、おそらく境界が間違っています。
2. コンテキスト通信の非常に望ましい方法はイベントベースです。これは、スケーラビリティと信頼性の鍵です。同期通信が必要な場合でも、おそらく境界は間違っています。その上、同期通信はあなたのシステムを殺します。
3. あなたのドメインはあなたが思っているよりも最終的に一貫性があります。みんなのように。すべてを100％一貫性のあるものにしようとしないでください。そこには実用的な意味はありません。
4. コンテキストを調整する必要はありません。それらは自己完結型です。人間のように。

このアプローチにより、高度な自律性、保守性、信頼性のあるサービスが得られます。コンテキスト境界を定義する例を確認したい場合があります。