1

アグリゲートごとに 1 つのリポジトリーを持つことをお勧めします。

ただし、同じ集計オブジェクトを 2 つの異種データ ストアから取得できる場合があります。背景の場合、そのオブジェクトは次のとおりです。

  1. データ ストアAから取得(リモートおよび読み取り専用)
  2. 検証のためにユーザーに提示される
  3. 検証時、データ ストアBにインポート(ローカル & 読み取り/書き込み)
  4. データ ストアBから取得して変更することができます。

明らかに (またはそうではない)、そのための一意の集約リポジトリを作成することはできません。ある時点で、オブジェクトがどのデータ ストアからフェッチされたかを知る必要があります。

ドメイン層がインフラストラクチャを無視する必要があることを考えると、私の特定のケースでは、リポジトリ パターンと一般的な DDD を適切に実装する方法についての私の理解が何らかの形で崩れます。

何か問題がありましたか?

4

1 に答える 1

4

何か問題がありましたか?

あなたが間違っていたのは、同じデータに対して2つのデータストアを持っていることだと私には思えます。

実際にこの冗長性に十分な理由がある場合、2 つの集約は何らかの点で異なる必要があり、それはそれらを別々の集約と見なして 2 つのリポジトリを持つことを正当化する可能性があります。

それらを単一の集約として扱いたい場合、単一のリポジトリが正しいデータストアを明確にして処理する方法を知っている必要がありますが、ドメイン モデルから離れたデータストアの知識をカプセル化する必要があります。

編集:

コメントで説明されているように、1 つのデータストアが読み取り専用で、もう 1 つのデータストアが変更可能なローカル コピーである状況では、実際には 2 つのデータストアを持つことが強制されます。リポジトリは両方のデータストアを認識し、ローカルで何かが見つからない場合にのみリモートの読み取り専用ストアを使用する必要があります。リモートから何かを取得するとすぐに、それをローカルに保存し、その後ローカル コピーを使用する必要があります。

このロジックはキャッシング プロキシのようなものですが、リモートは読み取り専用でローカルは読み書き可能であるため、厳密にはそうではありません。リポジトリで使用されるサービスに抽出するのに十分なロジックが含まれている可能性がありますが、ドメインには公開しないでください。

この状況には、考慮する必要があるいくつかのリスクもあります。何かをローカルに保存すると、同じデータの 2 つのバージョンができ、同期が取れなくなります。あなたがローカルを変更した後に、リモートの書き込みアクセス権を持つ誰かがそれを変更した場合、あなたはどうしますか?

于 2011-03-14T11:22:42.847 に答える