ドメイン駆動設計入門Chapter5

リポジトリとは

• ソフトウェア文脈のリポジトリはデータの保管庫です
• リポジトリはデータを保存・復元する処理を抽象的に扱うためのオブジェクトです

💡  オブジェクトを繰り返し利用するには、データベースにオブジェクトのデータを保存・復元する必要がある。特にエンティティはライフサイクルのあるオブジェクトなので、プログラムが終了したからといって消えてしまっては困る。

リポジトリを経由させる

• リポジトリはドメインオブジェクトと異なり、ドメインの概念を由来するものではない
  • ドメインと無関係ではなく、ドメインオブジェクトを技術的要素を由来としたコードで侵食されるのを防衛するもの
  • リポジトリはドメインモデルを表現するドメインオブジェクトを際立たせる役割がある
  • ドメインをうまく表現するというドメイン設計の構成要素としてリポジトリは欠かせない存在である

リポジトリの責務

• ドメインオブジェクトの永続化・再構築を行うこと
  • 永続化とは、インスタンスを保存して復元できるようにする

リポジトリにデータベースへの保存・復元の処理を記述して値オブジェクトやエンティティにDIして使用する

リポジトリのインターフェース

• リポジトリはインターフェースで定義されている
• 重複チェックをリポジトリに定義するアイデアが浮かぶかも知れないがリポジトリの責務ではない
  • あくまでもオブジェクトの永続化である
    • 重複チェックのロジックはドメインサービスに記述するべき
      • インフラストラクチャにまつわる処理をドメインサービスに書きたくなくリポジトリに定義する場合は具体的な重複確認のキーを引き渡す

テストによる確認

• テストを行うための手間が積み重なると開発者は次第にテストに対して誠実でなくなっていく
  • ある程度経験を積んだ開発者は記述したコードが「おそらく」意図した通りに動作するだろうと判断できてしまう
    • そのテストを多大な労力をかけて書くのはコストと対価が見合わないと感じられてしまう
      • テストをしなかったコードに対して、開発者ができることは祈りを捧げ得ることだけである
        • 願いは不安の裏返しであり、祈りを捨てる必要がある

テスト用のリポジトリを作成する

• テストを行う際に特定のインフラストラクチャを準備するのは億劫
  • メモリをデータストアとしてインメモリで動作するようにする
    • インスタンスを保存する媒体としてメモリを利用する際にもっとも扱いやすいのは連想配列である

インメモリとは、ソフトウェアを実行する際、使用するプログラムやデータのすべてをメインメモリ（RAM）上に読み込み、ストレージ（外部記憶装置）を使わないこと。特に、そのような方式のデータベースを「インメモリデータベース」という。

• テストのFindメソッドでは検索してヒットしたインスタンスをそのまま返却せずにディープコピーして返却する
  • 復元したインスタンへの操作がリポジトリ内で保持しているインスタンスにまで影響が出てしまうのを防ぐため

ディープコピーとは、オブジェクトのみをコピーではなく、オブジェクトとメモリ上にロードされたデータの両方をコピーすること

• saveメソッドでも同様にディープコピーを行う
  • 保存処理後にリポジトリ内部のインスタンスに影響が出てしまうのを防ぐため

ORMでもリポジトリに定義できる

リポジトリに定義されるふるまい

永続化に関するふるまい

• Saveメソッド、永続化のふるまいは永続化を行うオブジェクトを引数にとる
• Updateメソッド、対象の識別子と更新項目を引き渡して更新させるようなメソッドは用意しない
  • オブジェクトが保持するデータを変更するのであれば、オブジェクト自身に依頼するべき
• Deleteメソッド、削除のメソッドはリポジトリに定義する

再構築に関するふるまい

• Findメソッド、例としてユーザ名の重複が発生しているかを確認するために全建取得する必要がある
  • 対象となる前オブジェクトを再構築するメソッドを定義する
    • オブジェクトの数によってはリソースを食い潰してしまうので慎重になる必要がある
      • 探索を定義する際には適したメソッドを定義する