メモが滞ってる。。。第10章「集約」のメモを。
過去メモ
- IDDD本もくもく読書会をやってみたメモ#1
- IDDD本もくもく読書会メモ#2（第3章 コンテキストマップ）
- IDDD本もくもく読書会メモ#3（第4章 アーキテクチャ）
- IDDD本もくもく読書会メモ#4（第6章 値オブジェクト）
教材
CodeZine の記事 も第9章から更新が止まってしまっていてつらい。
メモ
10.2 ルール：真の不変条件を、整合性の境界内にモデリングする
整合性の境界の論理的な意味は、「その内部にあるあらゆるものは、どんな操作をするにかかわらず、特定の不変条件のルールに従う」ということだ。
- 境界づけられたコンテキストを適切に設計すれば、どんな場合でも、ひとつのトランザクション内で変更する集約をひとつだけに絞り込める
10.3 ルール：小さな集約を設計する
- モデルの一部分をエンティティとしてモデリングしたくなったらどうするか
- その部分自体が今後も変わり続けるものなのか、あるいは変更したくなったときに丸ごと置き換えれば済むのか考える
- 丸ごと置き換えられるならエンティティではなく値オブジェクト
- ユースケースを鵜呑みにするな
10.4 ルール：他の集約への参照には、その識別子を利用する
- 集約の合成構造？
- 集約から別の集約（へのルート）への参照を持つのはOK
- １つのトランザクションで参照する側とされる側の両方を更新してはならない
- 集約そのものへのポインタではなく、一意な識別子へのポインタを保持する
- Product ではなく ProductId （値オブジェクト）を持つ
10.5 ルール：境界の外部では結果整合性を用いる
- ひとつの集約上でコマンドを実行するときに、他の集約のコマンドも実行するようなビジネスルールが求められるのなら、その場合は結果整合性を使う
- 一方のインスタンスが変更されてから、もう一方のインスタンスが変更されるまでの遅延が、どの程度許容されるかをドメインエキスパートにたずねてみよう
- 現実的な手段としては、トランザクションの最後にドメインイベントを発行する
- 誰の役割かを考える
10.6 ルールに違反する理由
10.7 発見による知見の獲得
- 例：バックログアイテム：タスク = 1 : n の関係にある
- 一般的な利用シナリオを頭に浮かべながら試算する、という話が書かれている
- バックログアイテムの状態とタスクの残作業の総計は結果整合性にすべきか？
- メモリの消費
10.8 実装
- 集約のパーツは可能な限り、エンティティではなく値オブジェクトにする
public class Product extends ConcurrencySafeEntity { private Set<ProductBacklogItem> backlogItems; private String description; private String name; private ProductDiscussion ProductDiscussion; // VO private ProductId productId; // VO private TenantId tenantId; // VO }
- デメテルの法則（最小知識の原則）：任意のオブジェクトが自分以外（サブコンポーネント含む）の構造やプロパティに対して持っている仮定を最小限にすべきである
- 命じろ、たずねるな（Tell, Don't Ask）：
- 集約に依存性の注入は避けた方がいい？
Q
- 誰の役割かを考えてトランザクション整合性か結果整合性かを決める、というのは絶対なの？
- -> あくまで指針の１つと捉えておくのが良い
