Repository
永続化機構の詳細な実装や利用方法の違いなどを隠蔽することが目的
あるAggregateのcollectionがメモリ上にあると錯覚させるように、設計されるべき どのデータストアに対して検索や更新しているかを意識させない
例えば、データストアが、MySQLなのか、Redisなのかなどは利用者は意識しない
引数で、条件を指定し、
返り値がAggregateなので、仮に永続化機構が訳のわからんデータ構造になっていても、内側が汚染されることはない
この図がわかりやすい
https://gyazo.com/e9096f54ffc710b62c5c4b7225bf8e69 https://codezine.jp/article/detail/11048
Repositoryのmethods
どこまで汎用にするか？で大きく方針が変わる
最も具体的なものが、SQLを決め打ちするmethod
これでも、どこを変数に取るか？で再利用性は変わる
再利用性を上げればいいって話でもない
参考
初見では異常にわかりづらい
理解してたら読める
アンチパターンなど
Collectoin指向
RDB, インメモリ
add()という名前のmethod
永続指向
transactionは、repositoryが管理しない
repositoryはメモリ上のobjectに対して、追加や挿入をするだけ
commitするタイミングは、利用者に委ねる
Repositoryは、
objectを永続化層に格納する
objectを永続化層から取ってくる
でも、Entityで計算する必要があるものがあると
「RepositoryがAggregateを返す」って無理じゃない？
適当な初期値を返して、その後にEntityで計算する感じになるの？
あるいは、Repositoryの中でEntityの関数を呼べばいいmrsekut.icon
テストで使用するために、ダミーの実装で置き換えるのが容易になる(インメモリコレクションを使用するのが一般的)。
データの永続化の抽象を担う
どこに保存するか？を気にせずに、保存する処理を書く感じ
保存先はLocalStrageかも知れないし、DBかも知れないし
イメージとしてはinterfaceにはsaveがある感じ
code:ts
interface Repository {
save: (user: User) => void;
...
}
この実装時にLocalStrageやDBにsaveする具体的なロジックを書く
Gatewaysが知っていることの例
なんのDBを使っているのか
実装例
サーバー側の例