PofEAAのRepositoryパターンの解釈について

Question

PofEAA（またはドメイン駆動設計）におけるRepositoryパターンについて、現在のところ以下のように解釈している。

Repositoryオブジェクトとは、DAOやActiveRecordなど、DBの一行と対応するデータアクセスモジュールを集約し、特定のドメインモデルを生成する為の窓口である

しかし、この解釈でよいのかいまいち確信が持てず、またPofEAAやドメイン駆動設計を読んでみても疑問は解消されなかった。

そこで諸兄らに私の解釈の正否を問いたい。

正しいというのであればそれでよし。違うというのであれば、是非とも正しい解釈を教授して頂ければ幸甚である。

Answer 1

モデルの永続化を隠蔽するという点ではほぼ同じような解釈です。
細かいですが「生成」というよりも「取得・保存」のほうがしっくりきます。
「Repository」という単語は個人的には箱や倉庫のような何かを置いておく印象があるので
モデルを保存しておく、取り出すという操作が合うと思います。
「生成」は新しくモデルを作り出すのでファクトリの役目でしょうか。

DAOやActiveRecordなど

こちらの部分については解釈が異なります。
ActiveRecord パターンが採用されていれば Repository は不要ではないでしょうか？

Answer 2

Repositoryオブジェクトとは、DAOやActiveRecordなど、DBの一行と対応するデータアクセスモジュールを集約し、特定のドメインモデルを生成する為の窓口である

リポジトリは、ドメインモデル(問題や課題を解く考え方)を投影したドメインオブジェクト(設計・実装)を永続するための責務。 DAOやActiveRecordやDBですらも直接関係ありません。そのためリポジトリのメソッドは、ドメインのユビキタス言語由来ではなく、保存・削除・取得・検索の用語に対応したものになります。これは抽象的な操作を表しています。実装が何かは特に決まっていません。もちろん、多くはRDBMSに対応づくものになりますが、責務としては分離して考えたほうがよいですね。

なので、リポジトリの実装が具体的にRDBMSやNoSQLを利用したり、DAOやActiveRecordを利用するかはリポジトリから見た場合は要求によりけりです。ファイルやAPIサーバに対応したリポジトリもあってもよいでしょう。

**ある意味、DAOやRDBMS視点から考えるのではなく、ドメインオブジェクトのシリアライザー・デシリアライザーと考えて設計するとよいです。**RDBMSに対応するリポジトリ実装であれば、ドメインオブジェクトをテーブルのレコードへシリアライズする、もしくはレコードからデシリアライズするといった具合です。もちろん、リポジトリの内部実装でDAOやActive Recordを使うことも可能です。

Answer 3

ドメインの生成という見方はDDDのものですね。

PofEAAのほうはが先にあって、そこでは集約と隠蔽を目的としてパターンとされています。
ActiveRecordがあれば集約は不要というアーキテクチャ上の選択もありえますが、アーキテクチャの方針に依ります。

DDDのRepositoryはPofEAAのパターンを利用して、そこにDDD的な意味付けをしたものになります。