イベントストーミングと因果関係モデルとの関係
イベントストーミングのモデルは、
あるイベントAをトリガーにコンテキスト内の処理が走り、
そのコンテキスト境界内で内部の状態変化が起き、
最終的にドメインイベントを他のコンテキストに通知する
という意味で、原因と結果の因果関係モデルのようなメカニズムに感じたのが、今回の記事を書こうと思った背景です。
アナロジー：ドミノ倒しとしてのプロセス
イベントストーミングのモデルは、原因と結果の連鎖という意味で、複雑なドミノ倒しを設計するプロセスに非常に似ています。
1. 最初の「原因」 (トリガー)
ユーザーが 注文ボタンを押す (Command) という最初のドミノを倒します。
2. 処理と状態変化
・そのドミノ（Command）が、注文コンテキスト（Aggregate）内の処理を起動します。
・内部で「注文の状態が"保留中"になる」という状態変化が起きます。
3. 次の「結果」 (ドメインイベント)
この処理の結果として、注文が受け付けられた (Domain Event) という 新しいドミノ（オレンジ色の付箋） が倒されます。
4. 因果の連鎖
この注文が受け付けられたというドミノ（結果）が、今度は 次の「原因」 となり、通知コンテキストや在庫コンテキスト（Policy/Reaction）にぶつかります。
それにより、「顧客にメールを送る」「在庫を引き当てる」という次の処理が起動し、さらに新しいドメインイベントを生み出していきます。
なぜこの「因果関係モデル」が重要なのか？
イベントストーミングが単なる図と違うのは、
この「原因と結果」の連鎖
を明確にすることにあります。
ビジネスプロセスの可視化
複雑な業務プロセス全体が、「何が原因で、次に何が起きるのか」 というシンプルな因果の連鎖として、誰の目にも明らかになります。
依存関係の発見
「在庫引き当て」は、「注文受付」という原因がなければ絶対に起きない、という依存関係が明確になります。
これは、バリューステージの前後関係の明確化にも繋がります。
ボトルネックの特定
もし「注文受付」から「発送完了」までのドミノの連鎖に、異常に時間がかかっている
（＝因果の伝達が遅い）部分があれば、そこがボトルネックであると特定できます。
ESと因果モデルとの違い
さて、イベントストーミングとは、因果関係連鎖のモデルというメカニズムであることを上記で触れましたが、
因果 "ループ" はイベントストーミングで表現できません。
TOCの現状問題構造ツリーのように、原因と結果の因果ループになっている部分。
イベントストーミングは、TOCの現状問題構造ツリー（CRT）が得意とするような
「悪循環のフィードバックループ（vicious cycle）」 を、単一の図の中で明示的に表現することはできません。
なぜ表現できないのか？：時間の流れ vs 論理の構造
この違いは、両者のモデルが何を軸にしているかの違いから来ています。
イベントストーミング (ES): 時間軸モデル
ESの第一の軸は 「時間」 です。
イベントは（基本的に）左から右へと、不可逆的な時間の流れに沿って配置されます。
イベントAがイベントBを引き起こし、イベントBがイベントCを引き起こすという
一方向のドミノ倒し（因果関係） を描くのは得意です。
しかし、イベントCの結果が、過去のイベントAの発生条件に論理的に影響を与え続ける、といった
静的なフィードバックループを描くようには設計されていません。
TOC現状問題構造ツリー (CRT): 論理軸モデル
CRTの軸は 「論理的な因果関係」 です。
「もしAならば、Bである」「AとBが同時に起これば、Cである」という関係性をマッピングします。
時間の経過は副次的な要素であり、複数の問題（UDE: Undesirable Effects）が互いに原因であり結果でもあるような、「Aが悪化するからBが悪化し、Bが悪化するからAがさらに悪化する」といった
悪循環のループを視覚化することに長けています。
🎬 アナロジー：映画のフィルム vs 人物相関図
イベントストーミング
物語の筋書きを時系列に沿って並べた 「映画のフィルム」 です。
物語は前に進むだけで、フィルムが逆再生されたり、ループしたりすることはありません。
TOCのCRT
ドラマの登場人物たちの関係性を描いた 「人物相関図」 です。
「AはBを憎んでいる」「BはCに借金があり、CはAを恐れている」といった、互いに影響を与え合う恒常的な関係性を示します。
イベントストーミングは「ループ」をどう扱うか？
イベントストーミングで「ループのように見える」業務を表現することはできますが、
それはCRTのループとは異なります。
例：サブスクリプションの決済失敗
これは、ESのボード上では、CRTのような「円」にはなりません。
単に、タイムラインのさらに右側で、同じ名前のイベントが再び発生するだけです。
これは「論理的な循環」ではなく、「時間経過によるプロセスの再試行」 として表現されます。
結論
イベントストーミングは 「プロセスを設計・発見する」 ためのツール
TOCのCRTは 「既存の問題の根本原因と、その問題が持続する論理的な構造（ループ）を診断する」 ためのツール
です。両者は目的が異なるため、表現できることも異なります。
ただ、因果関係モデル（現状問題構造ツリー）を描く際に、ESモデルが根拠として有機的に作用するので、必ず対応付けておくことは推奨します。