私たちのプロジェクトでは、境界付けられたコンテキストのイデオロギーを適用しようとしていますが、明らかにパフォーマンスの問題に直面しています。たとえば、システム内のユーザーを表すためのさまざまなクラス (さまざまなコンテキスト) があります:Personコア ドメインのコンテキストとUserセキュリティ コンテキストです。したがって、集計ごとに 2 つの異なるリポジトリがありますが、それらは DB で同じテーブルを使用しており、同じデータにアクセスすることもあります。
この場合、db ラウンドトリップを最小限に抑える一般的な解決策はありますか? それを扱うORMはありますか、それともキャッシングシステムを自分でコーディングする必要がありますか?
upd:データベースはレガシー アプリのものであり、「そのまま」使用する必要があります。
したがって、集計ごとに 2 つの異なるリポジトリがありますが、それらは DB で同じテーブルを使用しており、同じデータにアクセスすることもあります。
2 つの集計が同じテーブルに格納されているという事実は、設計に問題があることを示しています。この場合、コア ドメインの BC (Person はここ) と ID/アクセス BC (User はここ) の 2 つの境界付けられたコンテキストがあるようです。BC は関連しており、後者は前者の上流と見なすことができます。Personコア ドメインの AはUser、アイデンティティ BC に対応する a を持っていますが、それらはまったく同じものではありません。
BC 間のこの関係を超えて、行動の所有権に関する疑問があります。たとえば、Person と User の両方が名前を持っている可能性があり、決定されるのは、名前を変更する動作の所有者が誰であるかです。これはいくつかの方法で実装できます。個人は独自の名前を持っている場合があり、変更は ID BC に伝播する必要があります。同様に、User は名前の変更を所有している場合があり、その場合、同期メカニズムを介して Person に伝達する必要があります。
全体として、問題は 2 つの方法で対処できます。まず、Person と User の集計を異なるテーブルに格納できます。特定のクエリは、これらのテーブルの 1 つだけを使用する必要があり、最終的に一貫性のある方法で同期できます。もう 1 つのアプローチは、動作ドメイン モデルをクエリ用に設計されたモデル ( read-model ) から切り離すことです。このようにして、特定の画面を提供するように設計された読み取りモデルを作成し、おそらく ORM の外部でも、カスタマイズされたクエリを持つことができます。
すべてのユーザーも個人である場合 (外部サービスも特別なユーザーとしてモデル化される場合があります)、ユーザーと個人がデータベースで共有する必要がある唯一のデータは、それらの識別子です。実際、ドメイン モデル内の各エンティティは、不変条件を保証するために必要なデータへの参照のみを保持する必要があります。
さらに、ユーザーはユーザー名で識別され、個人は何か他のもの (VAT コードなど..) で識別されると思います。
したがって、最も単純な最適化手法は、不変条件を保証する必要のない情報をエンティティにカプセル化しないようにすることです。
さらに、必要に応じて User から Person に簡単に渡すための効果的なコンテキスト マッピング手法が必要です。これには共有識別子を使用します。
例として、User クラスで Person の識別子を公開して、Person のリポジトリへの単純なクエリで必要なデータを提供できるようにすることができます。