実践ドメイン駆動設計第12章リポジトリメモ

リポジトリ
- 一般的に何かを保管するところ、中身が守られている
- 何かを保存して、その後取り出したときに保管した時と同じ状態で戻ってくる
- DDDのリポジトリも基本同じ
  - 集約のインスタンスをリポジトリ内に置く
  - その後リポジトリから同じインスタンスを取得してオブジェクトを得る
- 永続化する集約は一対一対応のリポジトリを持つ
- 時には複数の集約型がオブジェクトの階層を共有していることがあり、単一のレポジトリを共有している場合もある

11.1 コレクション指向のリポジトリ

コレクション指向の設計は古典的なアプローチ
- リポジトリでコレクションの標準的なインタフェースを真似る
- インタフェースを作るときは永続化メカニズムは考えず設計する
- この設計手法の場合、基盤となる永続化メカニズムに幾つかの機能が必要になる
Javaのコレクションを例にリポジトリのインタフェースを作る
- add, remove, addAll, removeAllなどを用意
- 今回の場合だとSetみたいな感じ
  - 同じものを入れても再度追加はされないなど
  - 集約が一意な識別子を持つのでそれを使ってチェックする
  - リポジトリ内にはそのインスタンスはそのまま残っている
    - インスタンスが変更されたからといってリポジトリのsaveメソッドを呼び出したりする必要はない
- コレクション指向のリポジトリはコレクションを真似て、永続化メカニズムはクライアント向けの公開インターフェースには一切現れない
永続化メカニズムにいくつか昨日が求められる
- 自身が管理するオブジェクトについて、変更履歴を暗黙のうちに追跡する仕組みがなければならない
  - 暗黙のコピーオンリード
    - リード時にコピー
    - 永続化するときにコピーと変更されたオブジェクトを比較して変更があったかチェック
  - 暗黙のコピーオンライト
    - 永続化オブジェクトをプロキシ経由で管理
    - 変更されたときは変更マークを付ける、トランザクションをコミットする際には変更マークつきのオブジェクトがあるかどうかを探し、見つかったすべてのオブジェクトをデータストアに書き出す
  - どちらもオブジェクトの変更を暗黙のうちに追跡できる
  - Hibernateみたいなものを使えば昔ながらのコレクション指向なリポジトリを作れる
  - パフォーマンス面でそういうものを使わないほうがいい場合もあるので、どんなツールにもトレードオフを考えること

11.2 永続指向のリポジトリ

コレクション指向のリポジトリが使えない場合は永続指向のリポジトリを考える必要がある
- addメソッドやaddAllの削除、更新の場合は常にsaveが必要など
- 新しく作ったり、変更を加えたりしたオブジェクトはデータストアに明示的にpull
  - 常に更新ということになる
  - 変更を追跡したりトランザクションの境界をサポートしたりするユニットオブワークが提供されていない
- GemFireやOracle Coherenceを使う場合Mapのような実装
- MongoDBなどはオブジェクトのコレクションのような扱い => これもキーバリューで保存されMapのようになる
- Javaの標準シリアライズだとパフォーマンスに問題ある場合があるので、高速かつコンパクトな手段を使って、集約と格納用の形式の変換をできるようにしておきたい。
MongoDBなどの実装例
- addやaddAllはなし、明示的なsaveが必要
- インターフェース的にはコレクション指向のほうがわかりやすそうに見えるが、内部実装で差分をチェックしないといけない分ちょっと怖そう