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