DDDを読んでる3

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

今日は第6章を読んだ。

Railsで行き当たりばったり雑にカスケード削除してたけど、集約を読んですっきりした。ルートエンティティを設定して、集約外からはルートエンティティ以外にはアクセスさせなきゃいいのかー。なるほど。図にするとよくわかるなぁ。今ならRubyにもぼっち演算子(&.)ついたし、よりやりやすくなるな。

ファクトリはようわからんかった。「集約全体を生成するのが複雑になったり、内部構造をさらけ出し過ぎていた場合」、に使うらしいので、この場面にあったら読みなおそうと思う。

リポジトリは、これはエンティティと分けた方が良いよなぁ、と。Railsのモデルで別にフォームを作る試みあるけど、このフォームがエンティティまたは値オブジェクトなのよな。Railsのモデルはリポジトリとエンティティがごっちゃになってて、デカイんだよね。DHHは勉強家らしいので、当然DDDも読んでるはずで、未だにActiveRecordがこの形なのはなんか理由があるんだろう。

• 第6章 ドメインオブジェクトのライフサイクル
  • 集約（AGGREGATES）
    • 例6.1——購入注文の整合性
  • ファクトリ（FACTORIES）
    • ファクトリとその場所を選択する
    • コンストラクタがあればよい場合
    • インタフェースを設計する
    • 不変条件のロジックはどこへ置くべきか？
    • エンティティファクトリ対値オブジェクトファクトリ
    • 格納したオブジェクトを再構成する
  • リポジトリ（REPOSITORIES）
    • リポジトリに対して問い合わせる
    • クライアントのコードはリポジトリの実装を無視するが、開発者はそうではない
    • リポジトリを実装する
    • フレームワークの範囲内で作業する
    • ファクトリとの関係
  • 関係データベースに合わせてオブジェクトを設計する