cross-aggregate-constraints

集約間の制約チェック

集約間の制約に直面したら、まず要件を疑い、次に技術的制約を理解し、最後に覚悟を決める。

典型的な問題

「集約Aのユースケースで集約Bの状態を確認したい」という要求が発生する。

例: 「一つでも商品が紐づいているブランドは削除できない」

  Brand集約（削除したい）←── 制約チェック ──→ Product集約（紐づき確認）

この種の要求に対して、安易に技術的解決策に飛びつくべきではない。

ステップ1: 要件を疑う

技術の前に、ビジネス要件自体を問い直す。

問い直しのフレームワーク

その制約は本当に必要か？
    ↓
ライフサイクル全体で考えるとどうなるか？
    ↓
実運用では実質的にどういう制約になるか？
    ↓
複雑な実装に見合うビジネス価値があるか？

具体例: ブランド削除制約

「一つでも商品が紐づいているブランドは削除できない」を問い直す：

観点	分析
初期状態	ブランド登録時は商品ゼロ。削除可能
運用中	ほとんどのブランドに何かしらの商品が紐づく
実質的な制約	「ブランドは削除できない」と同義になる
結論	複雑な制約チェック機構を作る意味があるか再検討すべき

要件緩和の選択肢

緩和案	説明
論理削除	ブランドを「非アクティブ」にする。商品紐づきチェック不要
制約の廃止	ブランド削除自体を禁止し、制約チェックを不要にする
条件の変更	「N日以上商品が紐づいていないブランドのみ削除可」等
許容	紐づき先のないゴミデータの存在を受け入れる

ステップ2: そもそもモデリングの問題ではないか

集約間の制約が必要に見える場合、集約の境界が間違っている可能性がある。

トランザクションは複数のエンティティにまたがりますか？ この質問の答えがイエスならば、間違った集約ルートを持っていると言えるでしょう。 --- Lightbend Academy

関係性に基づく判断フロー

2つの「集約」を常に一緒に操作する必要がある場合：

A : B の関係は？
    ├─ 1:1 → 同一集約に統合を検討
    │         例: Task(report: TaskReport)
    │         → 1トランザクションで不変条件を維持できる
    │
    ├─ 1:N（少量） → 要件調整で小規模化できないか検討
    │         → 可能なら同一集約に統合
    │
    ├─ 1:N（大量） → 別集約 + 結果整合性
    │         → ドメインイベントで連携
    │
    └─ Bは純粋なクエリ要件か？
          ├─ YES → CQRSのリードモデル（プロジェクション）で対応
          │         → Bは集約ではなくビューとして構築
          └─ NO → ドメイン知識を持つ → 独立集約 + 結果整合性

具体例: Task と TaskReport

「TaskReportの作成を忘れるとまずい」ならば、両者は独立できない可能性が高い。

// 1:1なら同一集約に統合
class Task private constructor(
    val id: TaskId,
    val name: TaskName,
    val report: TaskReport  // 集約内に含める
) {
    companion object {
        fun create(name: TaskName): Task {
            val id = TaskId.generate()
            return Task(id, name, TaskReport.create(id))
            // TaskReport作成忘れが構造的に不可能になる
        }
    }
}

TaskReportが純粋なクエリ要件なら、CQRSのリードモデルとして構築すべき。集約ではなくプロジェクションで対応することで、制約チェック自体が不要になる。

ステップ3: Sagaの誤用を避ける

集約間の制約チェックにSagaを使おうとするのは、よくある誤用パターンである。