Webページに在庫レベルを表示したり、在庫のエディション番号を表示したりすることができます（在庫が本、雑誌などであるとします）。この情報は、インベントリドメインから取得されます。
この時点で気づく主なことは、ビューについて話しているということです。つまり、古いデータの使用は許容されます。
とはいえ、アグリゲート（変更がビジネスインバリアントに違反しないようにする責任がある）と対話する必要はありませんが、アグリゲートの状態の最新のコピーを表示する必要があります。
したがって、私が通常期待するのは、製品カタログに対して実行されるクエリと、在庫に対して実行されるクエリであり、ビューをサポートするために2つをDTOに構成するものです。
製品ドメインと在庫ドメインの両方の集合体をロードしますか？
これで終わりです。何も変更しないので、アグリゲートをロードする必要はありません。しかし、私たちは彼らの状態を必要としています。それをロードすることができました。そうは言っても、私は通常、2つのドメインが異なるプロセスで実行されていることを期待します。したがって、両方をロードするのではなく、両方を呼び出すことになります。
在庫数と在庫数の製品ドメインエンティティのプロパティをいくつか保持し、在庫エンティティが更新されたときにドメインイベントを使用してこれらを更新しますか？
「小川を渡らないでください。それは悪いことです。」
イベントを使用してドメインコンテキスト全体で情報を調整する：素晴らしいアイデアです。あるドメインに属している概念を別のドメインにプッシュすること：それ以上のことを除いて、素晴らしいアイデアの反対。
ドメインをクリーンに保ちたい。アプリケーション相互作用ドメインと、それはそれほど重要ではありません。したがって、たとえば、Inventoryアプリケーションが製品アプリケーションのサービスを呼び出して、ビューに追加する製品固有の概念を照会することは妥当です。またはその逆。
単一のアプリケーションを単一のドメインに制限する必要がある理由はわかりません。真実の情報源が1つである限り、トランザクションを好きなように配布できます。
しかし、これをよく考えてみると、上の例では、製品カタログと製品在庫用に2つのDBテーブルが存在する可能性があります。これらは同じ製品なので、同じ識別子を使用しますか？
それは簡単な方法でしょう。大まかに言うと、実世界のエンティティは同じなので、同じ識別子を使用します。2つの異なる境界コンテキストはそのエンティティを異なる方法でモデル化しますが、モデルは実際のエンティティではありません。
それが機能しない場合、ギャップを埋めるために使用するクエリが必要になります。これの最も一般的なバリエーションは、新しいエンティティが古いエンティティのIDを保持することです。これは、単一のBC内でも確認できます。申請者は、承認されるとクライアントになります。それは別の集計です（クライアントに関連付けられた状態は、申請者の状態とは異なる不変条件の対象となります）。そのため、永続化レイヤーがイベントストリームを使用している場合、新しい集約のストリームには別の識別子が必要になります。したがって、「この申請者はこのクライアントになった」と言う状態がどこかにあるでしょう。
または、データに1つのテーブルと1つのテーブル行を使用して、関連するデータを集計プロパティに単純にマップできますか？
うわぁ！ いいえ、それをしないでください。ビジネス上の理由なくトランザクションの競合を追加している。