前置き
なんでこういうイベントストーミングとかの話がCI/CD上でされていないのでしょうか？
これは、日本のIT業界の「サイロ化」 を象徴する現象です。
イベントストーミングのような高度なモデリング手法がCI/CDパイプラインの設計で（一般的に）語られないのは、主に2つの「ドメイン（領域）」が歴史的に断絶していたからです。
1. コミュニティと「ドメイン」の断絶
イベントストーミング (EventStorming)
ドメイン駆動設計 (DDD) の世界で生まれました。
これは、アプリケーション開発者やビジネスアナリストが、「ビジネスプロセス
（例：注文、決済）」という複雑な業務ドメインをモデル化するために使う手法です。
CI/CDパイプライン
DevOps / オペレーション（運用）の世界で生まれました。
これは、インフラエンジニアやSREが、「ビルド、テスト、デプロイ」という技術的な運用ドメインを自動化するために使う手法です。
歴史的に、「ビジネスロジックを設計する人」と「デプロイプロセスを設計する人」
は、異なる部署に所属し、異なるカンファレンスに参加、異なる課題意識を持ってました。
DDDの設計手法（イベントストーミング）を、インフラの運用プロセス（CI/CD）に持ち込んで設計するという発想自体が、この2つのコミュニティの境界を越えなければ生まれない、先進的なものなのです。
2. パイプラインが「アーキテクチャ」として扱われてこなかった
この対話で「パイプラインアーキテクチャ」と呼んでいるものは、多くの現場ではまだ
「アーキテクチャ（設計対象）」 とは見なされていません。
従来の認識
CI/CDは単なる「自動化スクリプト」や「ツール（Jenkins, GitLab）」の「設定」である。
わたしの認識
CI/CDパイプラインは、それ自体が 「イベント駆動で動作する、複雑なソフトウェアプロダクト」 である。
イベントストーミングは、複雑なドメインをモデル化するための強力な武器です。
しかし、CI/CDパイプラインを「単純なスクリプト」としか認識していなければ、そこにイベントストーミングのような強力なモデリング手法を適用しようとは思い至らないのです。
まとめ
結論として、 この2つの概念が一緒に語られないのは、それが無意味だからではなく、
「ビジネスドメイン（DDD）」と「運用ドメイン（DevOps）」 という、日本企業の組織内に根強く残る「サイロの壁」を乗り越えるのが困難だからです。