エリックエヴァンスのドメイン駆動設計を読んでいる(第2部 第6章-3)

リポジトリ

DBに格納されているオブジェクトを取ってきてインスタンスを作るということはパッと見た感じ新規にオブジェクトを作っているように映るかもしれないが、ドメインモデルとして考えるとそれは既に存在するオブジェクトであり、新規作成ではない。 これは別の場所に格納されていたライフサイクルの途中にあるオブジェクトを、コード上から扱えるようにするために再生成するということになる。

クライアントが再生成を行う際に、DBに永続化されているオブジェクトをクエリを発行することによって取得することができる。クエリの実行をクライアントが自由にできてしまうと、例えば不完全な形でオブジェクトを扱おうとしたり、集約の約束を無視したアクセスを行おうとしてしまったりすることがある。 その結果、ドメインロジックがクエリやクライアントコードに移されてしまうので、実装が複雑になり、保守できないプロダクトに変貌してしまう可能性がある。

今になって考えてみるとまさにこれと同じことをプロジェクトでやってしまっていたことになんかすごく罪悪感を感じます。。。ごめんなさいー

ともあれ上記のような問題が起こることでせっかくカプセル化してたのが無駄になってしまったわけです。

これを解決してくれるのがリポジトリパターンです。

リポジトリはエンティティのライフサイクルに関わる操作を提供する責務を持つ。 再生成したり、更新したり、削除したりといった操作を提供する責務を持つ。

ここで注意すべきは、リポジトリは要求されたオブジェクトを取り出すが、データベースアクセスなどの操作は全てカプセル化されていることだ。 リポジトリはオブジェクトを取り出すだけでなく、何らかの条件を満たすインスタンスの数といった値を返すこともできる。

まとめ

この一文がすごくまとまってていい感じです。

「グローバルアクセスを必要とするオブジェクトの各型に対して、あるオブジェクトを生成し、その型の全てのオブジェクトで構成されるコレクションがメモリ上にあると錯覚させることができるようにすること」

グローバルアクセスを必要とする=ルートエンティティですし、メモリ上にあると錯覚させる=再生成する操作がカプセル化されておりクライアントが意識せずに扱えることという意味だと思います。