MENU

『ドメイン駆動設計』第6章(集約) エヴァンス本 まとめ&感想

DDD

前回のふりかえり

  • 第5章の主旨
    • モデルを構成するものとして エンティティ・値オブジェクト・サービス の3つの要素がある。
    • オブジェクト間の関連・結合度を下げることで1つ1つの要素に集中することができ、ドメインを扱いやすくする。
    • モデルの本質的な(そのシステムで着目すべき)関連・制約を値オブジェクトやエンティティで表現することで、開発者は設計に手を入れやすくなる。

※　分量増えてきた気がするので、1章1記事はやめました。

第6章 ドメインオブジェクトのライフサイクル

  • 全てのオブジェクトにはライフサイクルがある。
    • ライフサイクルはオブジェクトによって異なる。
    • ライフサイクルの長いオブジェクトには他のオブジェクトとの依存関係もあるし、状態の変化も起こる。

→　そのようなオブジェクトの管理が課題になってくる

課題とは...

  • ライフサイクルを通じて 整合性を維持 すること。
  • ライフサイクルを管理するのが複雑でも、モデルが侵食されないようにすること。

→ この章では、上記の課題に 集約・ファクトリ・リポジトリ の3つのパターンで対応する。

集約(AGGREGATES)

  • 複雑な関連を持つモデルは、モデル全体で一貫性を保つのが難しい
    • バランスの取れた解決策が必要
      • ドメイン内の 境界を定義 し、所有権をはっきりさせる ことで解決を図る

集約とは

関連するオブジェクトの集まり。データを変更するための単位。

  • 一つの集約が持つもの
    • 境界
      • 集約の内部に何があるかを定義するもの
    • ルート(エンティティ)
      • 外部のオブジェクトから参照できる唯一のエンティティ
    • エンティティ
      • 集約内でのみ同一性を持つ
      • 同じ集約内同士なら参照し合える

例) 一台の自動車の集約の中では、その車の持つタイヤがどのタイヤなのか把握しておきたい。(タイヤはエンティティとなる)
だが、そのタイヤを交換してリサイクルに出せば、同一性はたちまち必要が無くなる。

集約を実装するためのルール

  • データの削除・変更について
    • 境界内のオブジェクトが 変更 されるときは、集約全体の不変条件が満たされている必要がある
    • 削除する時は、集約内のあらゆるものを一度に削除 しなければならない

[不変条件とは]

- 不変条件とは、データが変更されるとき常に維持されないといけない一貫性のルール
- 不変条件をチェックする責務はルートエンティティにある
→　集約によって区切られるスコープにより、不変条件が維持されるべき範囲が示される
  • 同一性について
    • ルートエンティティはグローバルな同一性を持つ(集約の外でも同一性がある)
    • 集約内のエンティティは、集約内でのみ同一性を持つ
  • 集約をまたいだ参照について
    • 他の集約からは、ルートエンティティ以外参照できない
    • ルートエンティティは集約内エンティティへの参照を他のオブジェクトに渡せるが、受け取ったオブジェクトは単一の操作でしかそれを使えない(保持しない)
    • ルートエンティティが他のオブジェクトに値オブジェクトの コピー を渡すこともある

→　ルートがアクセスを制御することで内部が知らないうちに変更されるのを防ぐ

思ったこと・気になったこと

  • 最初集約の具体的な姿を想像できずに困惑していたけど、しょぼちむさんのこの一言がすごい腑に落ちた。

    マイクロサービスみたいな話だ...！ API化とブラックボックス

  • 少しずつ込み入った話になってきた。 集約もファクトリもやりたいことはわかるんだけど、自分で読んで書いてをやらないと本当の意味では理解できないんだろうなあ。

参考