リポジトリ その１のつづき
リポジトリ その２
ドメイン駆動設計の目標は、技術ではなく、ドメインについてのモデルに焦点を合わせることによって、よりよいソフトウェアを作ることである。(第二部第六章より)
なので、クライアント（特に"アプリケーション層")が直接データベースのクエリにアクセスすると、モデルではなくて、技術を扱っていることになり、ともすると、集約やオブジェクトのカプセル化を迂回しモデルが単なるデータの入れ物になってしまいます。
クライアントが必要とするのは、すでに存在するドメインオブジェクトへの参照を手に入れる、実用的な手段(第二部第六章より)
永続化されたオブジェクトはライフサイクルの中期です。
なので、データベース技術を使ってオブジェクトを”生成”するということではなく、なんでもいいから、"既にあるオブジェクト"の参照を手に入れることが大事です。
むしろ、オブジェクトが**"既にある"**ものとしてシームレスにオブジェクトの参照を手に入れるように実装したいものです。
メモリ上にあると錯覚させるようにすること(第二部第六章より)
リポジトリパターンはこのために使用します。
クエリで何をどう取得するか
基本SQLでどんな値を取得するクエリを書いても自由です。
ただ、ドメイン駆動設計では、特に値オブジェクトは集約のルートから辿って取得するべきです。
それは永続化されたオブジェクトでも同様で、
永続化された値オブジェクトを見つけるには、それをカプセル化する集約のルートとして機能するエンティティから関連を辿るのが普通である。(第二部第六章より)
上記から、クライアントが直接クエリを使用すると、このようなドメイン駆動設計の利点を活かしたオブジェクトの活用法から離れ、なんでもグローバルに取得するようになってしまいます。
リポジトリパターンを使用するもう一つの理由が集約の単位でオブジェクトを再構成するためです。
(例外として、"列挙"の取得など、まれではあるが、値オブジェクトをクエリで取得することがあります)
リポジトリパターン
リポジトリでは、これまで読んできたように、クエリなどの技術的な解決策をカプセル化します。
簡単なモデルは以下のような感じです。
明日も引き続きリポジトリを読んでいきます。