具体的には、2 つのシステム間で: システム A のドメインは、システム B のアプリケーション サービス/リモート ファサードを呼び出すことができますか?
たとえば、注文システムのドメインに Order エンティティがある場合、その Order エンティティの検証メソッドは Stock Keeping Service のアプリケーション サービスを呼び出して、注文を満たすのに十分な製品の在庫があることを確認する必要がありますか?
私の本能は、これは正しいやり方ではないということです。
これは以前のやや複雑な質問の簡略化されたバージョンです: さまざまなドメイン駆動設計システム間の統合 この以前の質問を参照する必要はありません。
私の意見では、このような問題を克服する方法はたくさんあります。まず、ドメイン モデルが他のドメイン モデルにアクセスできる必要があるのはなぜですか。
a)より複雑なドメインモデルを作成する場合 ==> このドメインモデルは、ViewModel を作成するための Service 層のユーザーになることができます。==> このビューモデルはクライアントに返されます。
この場合、アセンブルはドメイン層ではなく、サービス層に参加する必要があります。つまり、ドメイン モデルと隣接するサービスに何らかの要求を送信し、それらから結果を取得し、それらを特定の ViewModel にまとめて構成し、最終的に結果をクライアントに返します。
b) ドメイン モデルは、いくつかのビジネス ルールのチェックを担当します。それらのいくつかは他のシステムでチェックされるため、ドメイン モデルで隣接するシステムにアクセスすることを決定したとします。
ドメインモデルの責任（システムに属する）は、システムに関するいくつかのルールを正確にチェックすることであり、その境界の外にあるものではないことを考慮してください。つまり、ドメイン モデルが他のシステム ドメインにアクセスできないようにする必要があります。これらのシステム間に依存関係があります。サービス指向アーキテクチャに基づくアプローチは適切ではありません。これは疎結合設計に反します。代わりに、サービス層でこれらのシステム間を調整する必要があります。サービス層は、いくつかの要求をさまざまなシステムに送信し、それらから何らかの応答を取得します。最終的な決定は、全体的な結果に従って行われます。
まず第一に、アーキテクチャを検討する価値があります。ドメイン ロジックを別のドメインに直接フックする必要があるのはなぜですか? 他のドメインが公開しているデータを消費できませんか? そうでない場合、本当に 2 つの分離したドメインについて話しているのでしょうか、それとも本当に同じ境界付けられたコンテキストの一部なのでしょうか?
他のシステムが閉じたシステムであり、拡張できない可能性があります。また、他のシステムがイベントに基づいてデータを公開しておらず、API を介してのみアクセスできる場合もあります。その場合、ドメイン モデルでエージェントを使用することをお勧めします。つまり、ドメイン ロジックには、リモート システムに接続するがローカルのように動作するエージェント (プロキシ) が含まれている必要があります。これにより、実際のロジック/データがローカルではないという事実もカプセル化されます。