前回のふりかえり
- 第6章(ファクトリ)の主旨
- ファクトリはオブジェクト生成を責務として担うもの
- オブジェクトや集約の複雑な生成作業をファクトリに任せることで、オブジェクト本来の責務に集中することができる。
第6章
リポジトリ(REPOSITORIES)
- DBなどに永続化されたオブジェクトを取り出してインスタンス化する= 再構成
- 上記のケースはライフサイクル的には 中期 に属する。(新規のオブジェクトではない)
- 上記のように、永続化層からデータを取り出してインスタンス化する時も、不変条件 などのルールは守らないといけない
- これをインフラ層が持ってしまうと、ビジネスロジックがインフラ層に流出する
リポジトリとは
永続化層へのデータ追加・削除・オブジェクトの再構成を責務とするもの
- グローバルなアクセスが必要なエンティティ(ex. 集約ルート)に対して提供される
- このような複雑な処理を カプセル化 することでモデルに焦点を合わせることができる
リポジトリの実装
- データがメモリにあろうがDBにあろうが、クライアントがやることは何も変わらないにするのが理想
- 格納と取り出し、問い合わせの仕組みをカプセル化する
[留意点]
- 型を抽象化 する
- 取引注文のリポジトリを作って、買い注文と売り注文どちらも扱えるようにしてOK
- クライアントから切り離す利点を活かす
- 永続化の戦略を変更しやすい。テストしやすい
- トランザクション制御をクライアントにゆだねる
- リポジトリが管理しない方が単純になる
ファクトリとの関係
- ファクトリは、新しいオブジェクトを生成する
- リポジトリは、古いオブジェクトを見つけ出す(=再構成する)
→ リポジトリがオブジェクトの生成をファクトリに委譲できる
※ ↑ができると、「探して、なければ生成する」という機能を作りたくなるが、新しいオブジェクトと既存のオブジェクトを一緒くたにしてしまう。オブジェクトのライフサイクルを混ぜてしまうのは混乱の元
関係データベースに合わせたオブジェクト設計
- データベースとオブジェクトは性質のかなり異なる存在。双方の不整合を防ぐには、それなりの歩み寄りが必要
- オブジェクトは、モデルの持つ豊かさを多少犠牲にする
- データベースは過度の正規化を避ける
→ データベースとオブジェクトの不整合は、分析モデルと設計モデルの分離につながる
- オブジェクトの外部にあるシステムからアクセスさせない
- 外部システムには不変条件を強制できない。外部から値を変えられてしまうと対応しきれない
思ったこと・気になったこと
- オブジェクトとデータベースを近づけるためにある程度の非正規を許容するというところが一番印象に残った。正規化するとオブジェクトの姿とかなんもわからんなあと思ってたのは強ち間違いではなかった？
- システム上で新しくオブジェクトを作るのと、データベースの情報からオブジェクトを作るのは全然性質の違う話だったんだなあ
