読者です 読者をやめる 読者になる 読者になる

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

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

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

11.2 永続指向のリポジトリ

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

実践ドメイン駆動設計

実践ドメイン駆動設計

実践ドメイン駆動設計 (Object Oriented Selection)

実践ドメイン駆動設計 (Object Oriented Selection)

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

エリック・エヴァンスのドメイン駆動設計

エリック・エヴァンスのドメイン駆動設計