j5ik2o/okite-ai/cross-aggregate-constraints

例: 「一つでも商品が紐づいているブランドは削除できない」
 
  Brand集約（削除したい）←── 制約チェック ──→ Product集約（紐づき確認）

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

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

// 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作成忘れが構造的に不可能になる
        }
    }
}

Sagaの正しい適用:
  注文受付 → 在庫引当 → 決済処理 → 配送手配
  （どこかで失敗したら補償トランザクションで巻き戻す）
 
Sagaの誤用:
  「ブランドに商品が紐づいているか確認して、紐づいていたら削除を拒否する」
  → これは一連の操作ではなく、ただの制約チェック。Sagaの出番ではない

❌ 禁止: コマンド側 → リードモデル（クエリ側）を参照して判断
✅ 許可: コマンド側 → 他の集約にコマンド/メッセージで問い合わせ

// ❌ コマンド側がクエリ側に依存している
class CreateProductUseCase(
    private val productRepository: ProductRepository,
    private val brandReadModelRepository: BrandReadModelRepository, // リードモデルへの依存
) {
    fun execute(brandId: BrandId, productName: String) {
        // ① リードモデルでブランド存在チェック
        val brandExists = brandReadModelRepository.existsById(brandId)
        if (!brandExists) throw BrandNotFoundException(brandId)
 
        // ② 商品作成
        // ⚠ ①と②の間でブランドが削除される可能性（レース条件）
        val product = Product.create(brandId, productName)
        productRepository.store(product)
    }
}

// Akka/Pekko: 組み込みメッセージで存在確認
brandActorRef ! Identify(brandId)
// → ActorIdentity メッセージが返る
 
// Typed Actor: カスタムメッセージで状態確認
brandActorRef ! ExistsBrand(brandId, replyTo = self)

// ✅ 他の集約をリポジトリで参照するだけなら許可（更新は不可）
class CreateProductUseCase(
    private val productRepository: ProductRepository,
    private val brandRepository: BrandRepository, // コマンド側のリポジトリ
) {
    fun execute(brandId: BrandId, productName: String) {
        // コマンド側のリポジトリで存在確認（リードモデルではない）
        val brand = brandRepository.findById(brandId)
            ?: throw BrandNotFoundException(brandId)
 
        val product = Product.create(brandId, productName)
        productRepository.store(product)
        // ※ brandの更新はしない（参照のみ）
    }
}

可能: 商品ID → 商品集約のイベント履歴
不可: ブランドID → そのブランドに紐づく商品の一覧

Product集約 → ProductCreatedEvent → リードモデル更新
                                       ↓
                                    Brand-Product インデックス
                                       ↓
Brand削除時 → インデックスを参照して紐づき確認

集約間の制約チェックが必要になった
    ↓
1. その制約は本当に必要か？ → 要件を疑う
    ├─ 不要 → 制約を廃止。問題解消
    └─ 必要 ↓
2. そもそもモデリングの問題ではないか？
    ├─ 1:1の関係 → 同一集約に統合。制約チェック不要に
    ├─ 片方がクエリ要件 → CQRSのリードモデルで対応。集約不要
    └─ 独立した集約である必要がある ↓
3. Sagaを誤用しようとしていないか？
    ├─ 制約チェックにSaga → 不適切。Sagaは分散トランザクション管理用
    └─ OK ↓
4. コマンド側だけで解決できるか？
    ├─ YES → 他集約にリポジトリ/メッセージで参照（リードモデル依存は不可）
    └─ NO ↓
5. リードモデルでの「ベストエフォート」チェックで許容できるか？
    ├─ YES → リードモデル参照 + レース条件を許容 + 結果整合性
    └─ NO ↓
6. 強い一貫性が絶対に必要か？
    ├─ YES → 集約境界の見直しが必要（設計の問題）
    └─ NO → 結果整合性 + ゴミデータの許容