リポジトリパターンについて

Question

最近リポジトリパターンなるものを知り、調査しました。
そしてそのリポジトリパターンについて質問があります。
なお特に参考になったと感じたものは以下の記事です。
https://qiita.com/mikesorae/items/ff8192fb9cf106262dbf

まず大雑把にまとめると
リポジトリはDDDで言う集約と1対1に対応して作成されます。
そしてリポジトリはドメインオブジェクトを操作できるようにする責務を負います。（ただし、オブジェクトの正当性などのチェックはここでは行わない＝ビジネスロジックを持ち込まない）
以上から、リポジトリから取得したものは必ず集約内のオブジェクトも全て取得する必要があるかと思います。

しかし、実際にはその集約オブジェクトのみ欲しい場合があります。
例えば受注明細を持つ受注票をひとつの集約オブジェクトとみなした場合、受注票の一覧画面では受注明細まで取得する必要はありません。さらにどのような一覧を見せるのかはビジネスロジックとなるので、このような場合は、その一覧画面用のサービスクラスを作り、そこでリポジトリを介さず受注票のみを取得するものを提供すれば良いという考えで間違いないでしょうか？（リポジトリは、一覧画面から詳細画面に遷移するときなどに使用する）

もし他にもこのように実装するなどありましたらお教えいただけると幸いです。

Answer 1

参照先の記事を読んだ限りでは、リポジトリを経由してストレージにアクセスするという原則は更新系の処理に対するもので、参照系はそうではない、ということであるので、arisukeさんの理解に誤りはないと思います
小規模なアプリケーションの場合は、参照系の処理もリポジトリに置いてしまってもよい、という旨の記述もありますが

結局のところ、抽象的なリポジトリで隠蔽することによるもろもろのメリット(テストのしやすさ、DBの移行のしやすさ、要件があいまいな状態でも開発が進められるなど)や、集約によるメリット(複数のエンティティに跨る更新処理のようなバグの入り込みやすい一連の流れを一つのリポジトリに集約(隠蔽)できる)を損なわないような塩梅でリポジトリを用いるのがよい、とのことのようですね

Comments

[arisuke]

現在の個人的な考えとしては、基本的には参照系と更新系を切り分けたいと思っています。（もちろん書かれているように規模にもよると思いますが）
というのも参照系は多くの場合、テーブル結合が起こり専用のクラス（これはドメインオブジェクトではないため、アプリケーション層に置く）が必要になりますし、性能で問題となるのも参照系となるからです。
それと、そもそも更新系や参照系で変更が必要となる起点が異なるので、別々にしたほうが収まりが良いように感じているからです。

といっても結局のところ書かれているように、メリットなどを都度しっかり考えて適切にどのように使用するか選択していくということになりますが（この塩梅がすごく難しいですね）

少なくとも大筋では考え方が間違っていないということを確認できました。
ご回答ありがとうございました。