cross-aggregate-constraints

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

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

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

集合体間の制約チェックのための設計決定をサポートします (「集合体 A のユースケースでは、集合体 B の状態をチェックしたい」)。 Saga の不正使用の検出、ビジネス要件の再検討、CQRS/ES の技術的制約の理解、一貫性のないデータを許容するかどうかの決定が含まれます。 コードレビュー、アーキテクチャ設計、または要件分析中に集合体間の制約の問題に直面した場合に使用します。 ターゲット言語: 言語に依存しません。 トリガー: 「クロスアグリゲート制約チェック」、「別のアグリゲートの状態を確認したい」、「Sagaでの制約チェック」、「製品がブランドにリンクされているかどうかの確認」、「クロスアグリゲート検証」、「イベントソーシングによる逆引き参照」、「アグリゲートをまたぐビジネスルール」、「CQRS/ES制約」、「コマンド側で読み取りモデルを参照できますか?」などのアグリゲート間制約関連のリクエストによってアクティブ化されます。 「ユースケースで別の集合体を参照する。」 ソース: j5ik2o/okite-ai。