Aggregate design

集約設計

DDD における集約ルート・境界・不変条件の設計を支援する。

集約とは

トランザクション整合性を保証する境界である。集約内のすべてのオブジェクトは1つのトランザクションで一貫性を保つ。

4つの原則:

1. 集約ルートのみが外部から参照される — 内部エンティティへの直接アクセスを禁止する
2. 1トランザクション = 1集約 — 複数の集約を1トランザクションで更新しない
3. IDによる参照 — 集約間はIDで参照し、オブジェクト参照を持たない
4. 結果整合性 — 集約間の整合性はドメインイベントで保つ

集約境界の判断ツリー

この要素群を同じ集約にすべきか？
├─ 同一トランザクションで整合性が必要    → 同一集約
├─ 結果整合性で十分                      → 別集約
├─ ルートなしでは存在意義がない          → 同一集約（子エンティティ）
├─ 独立したライフサイクルを持つ          → 別集約
├─ 集約が10エンティティを超える          → 分割を検討する
└─ 異なるユーザーが同時に操作する        → 別集約（ロック競合を避ける）

集約設計のステップ

Step 1: 不変条件の特定

集約内で常に満たすべきビジネスルールを列挙する。

不変条件の例（注文集約）:
- 注文明細は最低1つ存在する
- 注文合計金額は明細の合計と一致する
- 確定済み注文の明細は変更できない
- 割引率は0%〜100%の範囲内である

質問で不変条件を引き出す:

• 「この操作が行われたとき、同時に保証すべきルールは何か？」
• 「この状態は他のどの状態と矛盾してはいけないか？」
• 「部分的に更新された状態が存在して良いか？」

Step 2: 集約ルートの決定

集約ルートの条件:
├─ グローバルな一意識別子を持つ
├─ 集約全体の不変条件を守る責務がある
├─ 外部からのすべての操作の入口となる
└─ 子エンティティのライフサイクルを管理する

Step 3: 集約の構造設計

集約ルート（Entity）
├── 子エンティティ（Entity）  — ルート内でのみ識別子を持つ
├── 値オブジェクト（Value Object） — 不変、等価性で比較
└── ドメインイベント（Domain Event） — 状態変更時に発行

Step 4: 操作の設計

集約ルートを通じてのみ状態を変更する。

設計原則:

• メソッド名はドメイン用語で命名する（addItem ではなく addOrderItem）
• セッターを公開しない。ビジネス操作としてメソッドを定義する
• 操作の結果としてドメインイベントを発行する
• 不変条件に違反する操作は例外を投げる

集約サイズの指針

指標	推奨	警告
エンティティ数	1〜5	10以上は分割を検討
コレクション要素数	上限あり	無制限は危険
不変条件数	集中している	分散している場合は分割候補
同時更新の競合	低い	高い場合は分割する

小さい集約を目指す。 Vaughn Vernon の原則: 「小さな集約を設計せよ」

集約間の参照

正しい参照:
  Order → orderId: CustomerId  （IDで参照）

誤った参照:
  Order → customer: Customer   （オブジェクト参照）

集約間の整合性は結果整合性で保つ:

1. 集約Aが操作を実行し、ドメインイベントを発行する
2. イベントハンドラが集約Bを更新する
3. 最終的に両方が整合する

アンチパターン

アンチパターン	問題	対処
God Aggregate	巨大な集約でパフォーマンス劣化	小さな集約に分割する
集約ルートのバイパス	内部エンティティへ直接アクセス	ルート経由のメソッドのみ公開する
複数集約の同時更新	トランザクション肥大化	ドメインイベントで結果整合性にする
Anemic Aggregate	集約がデータの入れ物のみ	ビジネスロジックを集約内に移動する

擬似コード例

examples/ ディレクトリに具体例がある:

• examples/aggregate-example.pseudo — 注文集約の設計例