Repository
Repository Pattern
永続化機構の詳細な実装や利用方法の違いなどを隠蔽することが目的
Aggregate単位で、永続化層との出し入れを行う
プログラムの外部との境界
直接的なアクセスを必要とするAggregate Rootに対してのみRepositoryを提供する
あるAggregateのcollectionがメモリ上にあると錯覚させるように、設計されるべき
どのデータストアに対して検索や更新しているかを意識させない
例えば、データストアが、MySQLなのか、Redisなのかなどは利用者は意識しない
引数で、条件を指定し、
返り値は、Aggregateか、AggregateのCollectionになる
OOPの場合、instantiateされたAggregateになる
返り値がAggregateなので、仮に永続化機構が訳のわからんデータ構造になっていても、内側が汚染されることはない
この図がわかりやすい
https://gyazo.com/e9096f54ffc710b62c5c4b7225bf8e69 https://codezine.jp/article/detail/11048
repositoryの返り値はAggregatemrsekut.icon
Repositoryのmethods
どこまで汎用にするか?で大きく方針が変わる
/kawasima/リポジトリクラスのメソッド設計
最も具体的なものが、SQLを決め打ちするmethod
これでも、どこを変数に取るか?で再利用性は変わる
再利用性を上げればいいって話でもない
ORM
参考
Repositoryによる抽象化の理想と現実/Ideal and reality of abstraction by Repository - Speaker Deck
/mrsekut-book-4798121967/187 (リポジトリ (REPOSITORIES))~
初見では異常にわかりづらい
理解してたら読める
#WIP
/miyamonz/repositoryとのやりとりを抽象するのではなく、repositoryとの間のデータを抽象しよう
https://zenn.dev/karibash/articles/4cc74e4705dc9c
Repositoryから別のRepositoryを呼ぶのは良いか悪いか
Repositoryのtest