リポジトリは本当に何をすべきでしょうか？

リポジトリパターンの多くを聞いたことがありますが、リポジトリが実際に何をすべきかを理解していませんでした。「リポジトリが実際にすべきこと」と言うとき、私は主にどのメソッドを提供すべきかを心配しています。たとえば、リポジトリは本当にCRUDメソッドを提供する必要がありますか、それとも何らかの種類のメソッドを提供する必要がありますか？

つまり、リポジトリにビジネスロジックを含めるべきですか、それとも単にデータストアと通信し、保存またはロードするエンティティを管理するためのロジックを含めるべきですか？

また、リポジトリは集約の永続性の単位であると聞いています。しかし、それはどうですか？これが実際にどのように機能するのか理解できません。IRepositoryCRUDメソッドを含むインターフェイスを1つだけ持つ必要があると考えました。その後、エンティティには、そのような型をデータストアから保存および取得するためのロジックが含まれます。

さて、リポジトリの概念に基づいたSpring Data Frameworkの良い例を見ることができます。

リポジトリには、データストアのみを扱い、ビジネスロジックが含まれることはほとんどありません（これはサービスレイヤー用に予約されています）。したがって、たとえば、エンティティを作成、破棄、および復元するメソッドを公開するCRUDRepositoryインターフェイスがあることを確認できるように、デザインを見てみましょう。PagingAndSortingRepositoryもあります。これは、正確にそのための追加機能、ソートやページングの結果などを追加します。

したがって、このフレームワークは、適切なリポジトリ設計を研究するのにおそらく良い場所です。

私の知る限り、Spring Data Frameworkで実装されている概念の多くは、ドメイン駆動設計：ソフトウェアの中心にある複雑性への取り組みという素晴らしい本に由来しています。

そのコピーを入手することを検討してください。

本からの小さな抜粋は説明します：

REPOSITORYパターンは、これらのソリューションをカプセル化し、モデルの焦点を取り戻すためのシンプルな概念フレームワークです。

リポジトリは、特定のタイプのすべてのオブジェクトを概念セット（通常はエミュレート）として表します。精巧なクエリ機能を除いて、コレクションのように機能します。適切なタイプのオブジェクトが追加および削除され、リポジトリの背後にある機械がそれらをデータベースに挿入またはデータベースから削除します。この定義は、初期のライフサイクルから最後までAGGREGATESのルートへのアクセスを提供するための責任の集合を収集します。

クライアントは、クライアントによって指定された基準（通常は特定の属性の値）に基づいてオブジェクトを選択するクエリメソッドを使用して、リポジトリにオブジェクトを要求します。REPOSITORYは要求されたオブジェクトを取得し、データベースクエリとメタデータマッピングの機構をカプセル化します。リポジトリは、クライアントが必要とする基準に基づいてオブジェクトを選択するさまざまなクエリを実装できます。また、いくつかの基準を満たすインスタンスの数などの要約情報を返すこともできます。いくつかの数値属性の一致するすべてのオブジェクトの合計など、集計計算を返すこともできます。

リポジトリは、クライアントからの大きな負担を取り除きます。クライアントは、単純な意図を明らかにするインターフェースと対話し、モデルに関して必要なものを要求できるようになりました。これをすべてサポートするには、多くの複雑な技術インフラストラクチャが必要ですが、インターフェイスはシンプルで、概念的にドメインモデルに接続されています。

したがって：

グローバルアクセスが必要なオブジェクトのタイプごとに、そのタイプのすべてのオブジェクトのメモリ内コレクションの錯覚を提供できるオブジェクトを作成します。既知のグローバルインターフェイスを介してアクセスを設定します。

オブジェクトを追加および削除するメソッドを提供します。このメソッドは、データストア内のデータの実際の挿入または削除をカプセル化します。いくつかの基準に基づいてオブジェクトを選択し、完全にインスタンス化されたオブジェクトまたは属性値が基準を満たすオブジェクトのコレクションを返すメソッドを提供することにより、実際のストレージおよびクエリテクノロジーをカプセル化します。実際に直接アクセスが必要なAGGREGATEルートに対してのみリポジトリを提供します。クライアントをモデルに集中させ、すべてのオブジェクトストレージとリポジトリへのアクセスを委任します。

ストレートなCRUDインターフェイスもビジネスロジックも提供すべきではありません。ビジネスロジックとデータベースを仲介します。インターフェイスはビジネスロジックの用語で表現する必要がありますが、ビジネスロジックのプリミティブのように、ビジネスロジック自体を実行することはできません。例として、電子メールシステムを構築するつもりだった場合、ユーザーとメッセージがあります。リポジトリは、ユーザーとメッセージに基本的なCRUD操作を提供しますが、GetUsersNewMessages（user）やGetSearchedMessages（user、searchTerms）などのメッセージのフィルタービューも提供します。

リポジトリは、ストレージの実装方法を隠し、データへの高速で柔軟なアクセスを可能にするクリーンなインターフェイスを提供するという考え方です。どのように行うかというよりも、何をすべきかという高レベルの条件で操作を維持することは、基盤となるバッキングストアにとって最適な方法でそれらを実装するための柔軟性を高めることを意味します。