同じエンティティに対して 2 つのインスタンスを作成しないように、どの集約ルートが既に作成されているかを追跡する責任をプロジェクト内のどのクラスが担当する必要がありますか。リポジトリは、作成したすべての集計のリストを保持する必要がありますか? はいの場合、どうすればいいですか？シングルトン リポジトリを使用する必要がありますか? 別のオプションは、この「キャッシング」を別のクラスにカプセル化することでしょうか? このクラスはどのように見え、どのパターンに適合しますか?
私はO/Rマッパーを使用していないので、それを処理する技術がそこにある場合、それを使用できるようにするために、それがどのように（どのパターンを使用するかなど）行うかを知る必要があります
ありがとう！
Martin Fowlerが説明したように、あなたはIdentityMapパターンについて考えていると思います。
ファウラーは、パターンの完全な説明（彼の本）で、読み取り/書き込みエンティティ（トランザクションに参加するエンティティ）と読み取り専用（理想的には一度だけ読み取り、その後メモリにキャッシュする必要がある参照データ）の実装に関する懸念について説明しています。 。
彼の優れた本を入手することをお勧めしますが、このパターンを説明する抜粋はGoogleブックスで読むことができます（「ファウラーアイデンティティマップ」を探してください）。
基本的に、IDマップは、データベースからロードされたエンティティオブジェクトをたとえばハッシュテーブルに格納するオブジェクトです。マップ自体は、現在のセッション（要求）のコンテキストで、できれば作業単位（読み取り/書き込みエンティティの場合）に保存されます。読み取り専用エンティティの場合、マップはセッションに関連付けられている必要はなく、プロセスのコンテキスト（グローバル状態）に保存できます。
キャッシングは、リポジトリではなく、サービス レベルで発生するものだと考えています。リポジトリは「ダム」であり、基本的な CRUD 操作のみを行う必要があります。サービスは、必要に応じてキャッシングを行うのに十分なほどスマートにすることができます (これはおそらく、低レベルのデータ アクセス ルールというよりはビジネス ルールに近いものです)。
簡単に言うと、どのコードでもリポジトリを直接使用することはできません。それができるのはサービスだけです。次に、他のすべてが関連するサービスをインターフェイスとして使用します。これにより、ビジネス ロジックやキャッシュなどを配置するための優れたラッパーが提供されます。
この「キャッシング」がリポジトリ以外の場所で管理されている場合、懸念が漏れていると言えます。
リポジトリはアイテムのコレクションです。リポジトリを使用するコードは、オブジェクトをリポジトリから取得するか、別の場所から取得するかを決定する必要はありません。
シングルトンは間違った寿命のように聞こえます。リクエストごとにする必要があります。IoC/DI コンテナーを使用している場合、これは簡単に管理できます。
同じ集計に対する複数の呼び出しを検討しているという事実は、アーキテクチャ/設計の問題を示しているようです。これらの最初と 2 番目の呼び出しがどのようなものであるか、および AR のまったく同じインスタンスが必要な理由の例を聞きたいと思います。