リポジトリパターンとは
リポジトリパターンはデータアクセスロジックをビジネスロジックから分離するデザインパターンです。
図にすると以下のようなイメージで、ドメイン層からデータの永続化に関する情報リポジトリクラスに移動します。またリポジトリクラスのインターフェースを切り、ドメイン層に置くことで、ドメイン層とインフラストラクチャ層の依存関係が逆転し、ドメイン層は永続化の関心事から分離されます。
リポジトリパターンのメリットは一般的に以下のような内容が挙げられます。
- ビジネスロジックとデータアクセスロジックを明確に分離できる
- モックリポジトリを使用することで、データアクセス層に依存せずドメインロジックをテストできる
- ドメイン層がインフラストラクチャ層に依存せず、両方がドメイン層で定義されたインターフェースに依存する
もちろん単体でも意味のあるデザインパターンなのですが、DDDの集約と組み合わせることでより良い効果を生み出します。
集約とリポジトリパターン
まず集約の簡単な説明を下記に記載します。
関連するオブジェクト（エンティティ、バリューオブジェクト）の集まりで、データの一貫性と整合性を保つための明確な境界を定義します。集約ルートは集約への唯一の入り口で、エンティティ（状態の変化があるもの）の変更を唯一許された存在です。
集約ルートにおけるデータの一貫性と整合性はデータベースのトランザクションのイメージではなく、集約全体として常に真であるべき条件をイメージして欲しいです。エンティティやバリューオブジェクト間を跨いで存在するビジネスロジックを含んだバリデーションという理解が個人的にしっくりきます。
それでこの集約が、DDDにおいて永続化の単位になります。しかし、集約は複雑なビジネスロジックを表現する為のもので、永続化や永続化された情報からの復元という関心ごとを持ちたくありません。そこで集約とリポジトリを1対1で持というのがDDDにおけるリポジトリパターンの設計です。
リポジトリは永続化の際は集約の内容をDBにマッピングし永続化を行い、取得の際はDBから読み取った内容を元に集約を再構築します。
これにより、集約（オブジェクト）があたかもメモリ上に存在するかのように扱うことが出来ます。
総括
個人的にリポジトリパターン単体だと理解が難しいかったのですが、DDDの集約とセットで考えたら比較的理解が進みました。リポジトリパターンで悩まれている方の力になれれば幸いです。