この記事は何？
ドメイン駆動設計を題材とした書籍「ドメイン駆動設計をはじめよう」を読みました。
非常におもしろく有用な内容なのでぜひみなさんにもおすすめです。
この記事では全部の内容を紹介するのは不可能なので、第12章のイベントストーミングに絞って紹介をしたいと思います。
要約を記載するだけでなく、AIエージェント型のVSCode拡張機能「Cline」 と一緒にイベントストーミングをやってみたので、その内容を紹介します！
なぜいまドメイン駆動設計か？
なぜ「ドメイン駆動設計」をテーマとしたのか？ これはまさにwithAI時代に必須の学びだと考えたからです。
みなさんが体感しているように、コーディングなどの定型作業はAIに取って代わられる可能性が高いと思います。 その中で、我々が顧客に価値を届けるために必要なものは、ドメイン知識、および、それをどのようにシステムに落とし込むかというスキルです。
イベントストーミングとは？
イベントストーミングは、グループでビジネスプロセスをブレインストーミングし、迅速にモデル化するためのローテクな活動です。
ある意味で、イベントストーミングはビジネスドメインの知識を共有するための実践的なツールと言えます。
イベントストーミングのステップ
Step1 : 発散的に探索する
イベントストーミングは探求する業務領域に関する業務イベントのブレインストーミングから始まります。
業務イベントは業務活動で起きた興味深い出来事（過去形で表現する）です。
Step2 : 時系列に並べる
Step1で洗い出した業務イベントを確認し、時系列に並べます。
まず、「正常系のシナリオ」のフローからはじめてください。
正常系が完了したら「代替シナリオ」を追加します。
エラーが発生するシナリオ、異なる意思決定が行われるシナリオです。
Step3 : 問題点を洗い出す
プロセス全体の中で注意が必要な点を特定します。
- ボトルネックになっている箇所
- 自動化できていない作業
- 文書化できていないものや業務知識が不足しているところ
Step4 : 転換イベントを見つける
文脈やフェーズの変化を示す重要な業務イベントを探します。
これらのイベントを「転換イベント」(pivotal event)と呼びます。
たとえば、「ショッピングカートが初期化された」「注文処理が開始された」「注文が出荷された」「注文が配達された」「注文が返品された」などは、注文処理プロセスの重要な変化を表します。
Step5 : コマンドを見つける
業務イベントは、すでに起こったことを説明します。
それに対して「コマンド」は、イベントあるいはイベントのフローを引き起こすものを説明します。
何かを指示する形式で表現します。
- キャンペーンを公開する
- 処理を取り消す
- 注文を送信する
コマンドが生成するであろうイベントの前に貼り出します。
特定のアクターによって実行されるコマンドは、そのアクター情報を追記します。
Step6 : ポリシーを定義する
コマンドのほとんどは、特定のアクターに関連づけられていません。
このステップでは、これらのコマンドを実行すると想定される「自動化ポリシー」を探します。
自動化ポリシーとは、あるイベントがコマンドの実行を引き起こすシナリオです。
コマンドがなんらかの判定条件を満たした場合にのみ実行されるんら、その判定条件も明記します。
Step7 : 読み取りモデルを見つける
読み取りモデルは、アクターが、コマンドを実行するかどうかを判断するために使う、対象領域の状態を表現するデータのビューです。
画面、レポート、通知などが該当します。
Step8 : 外部システムを追加する
このステップでは、外部システムを追加してモデルを拡張します。
外部システムとは、探求している業務領域の外側に存在するシステムの表現です。
コマンドを実行したり、イベントに関する通知を受けたりする可能性があるものが該当します。
このステップが終わった段階で、全てのコマンドは、
- アクターによって実行されるか
- ポリシーによって発動されるか
- 外部システムによって呼び出されるか
のいずれかになっているはずです。
Step9 : 集約を見つける
全てのイベントとコマンドを洗い出したら、関連する概念を集約として整理します。
集約はコマンドを受け取り、イベントを生成します。
Step10 : 区切られた文脈に分割する
イベントストーミングセクションの最後のステップとして、機能的に密接に関係していたり、自動化ポリシーを介して結合されていたりする集約を探します。
このような集約の集まりが、区切られた文脈の境界の自然な候補となります。
Clineとはじめるイベントストーミング！
Clineは、VSCode拡張機能型のAIエージェントです。
コーディングが得意タスクですが、今回試してみて上流工程の成果物作成にも結構使えると思いました。
やりとりの様子
基本的には、チャットでやり取りしますが、思考を深めるための対話ができます。
初期のプロンプト
長いので折りたたんであります。
とあるサービスの改善施策の承認フロー
<task>
今からイベントストーミングをデモンストレーションしてみたいと思います。
以下にイベントストーミングの手順（10個のステップ）を提示しますので、よく理解してください。
<イベントストーミングの手順>
## 12章 イベントストーミング
### イベントストーミングとは何か？
イベントストーミングは、グループでビジネスプロセスをブレインストーミングし、迅速にモデル化するためのローテクな活動です。ある意味で、イベントストーミングはビジネスドメインの知識を共有するための実践的なツールと言えます。
イベントストーミングセッションには「スコープ」があります：それは、グループが探求したいと考えるビジネスプロセスのことです。参加者は、タイムライン上に付箋紙で表されたドメインイベントの連続として、そのプロセスを探求していきます。ステップバイステップで、モデルはアクター、コマンド、外部システムなどの追加的な概念で強化され、最終的にそのすべての要素がビジネスプロセスの仕組みを物語るようになります。
### イベントストーミングのステップ
#### Step1 : 発散的に探索する
イベントストーミングは探求する業務領域に関する**業務イベント**のブレインストーミングから始まります。
業務イベントは業務活動で起きた興味深い出来事（過去形で表現する）です。
#### Step2 : 時系列に並べる
Step1で洗い出した業務イベントを確認し、時系列に並べます。
まず、「正常系のシナリオ」のフローからはじめてください。
正常系が完了したら「代替シナリオ」を追加します。
エラーが発生するシナリオ、異なる意思決定が行われるシナリオです。
#### Step3 : 問題点を洗い出す
プロセス全体の中で注意が必要な点を特定します。
- ボトルネックになっている箇所
- 自動化できていない作業
- 文書化できていないものや業務知識が不足しているところ
#### Step4 : 転換イベントを見つける
文脈やフェーズの変化を示す重要な業務イベントを探します。
これらのイベントを「転換イベント」(pivotal event)と呼びます。
たとえば、「ショッピングカートが初期化された」「注文処理が開始された」「注文が出荷された」「注文が配達された」「注文が返品された」などは、注文処理プロセスの重要な変化を表します。
#### Step5 : コマンドを見つける
業務イベントは、すでに起こったことを説明します。
それにたいして「コマンド」は、イベントあるいはイベントのフローを引き起こすものを説明します。
何かを指示する形式で表現します。
- キャンペーンを公開する
- 処理を取り消す
- 注文を送信する
コマンドが生成するであろうイベントの前に貼り出します。
特定のアクターによって実行されるコマンドは、そのアクター情報を追記します。
#### Step6 : ポリシーを定義する
コマンドのほとんどは、特定のアクターに関連づけられていません。
このステップでは、これらのコマンドを実行すると想定される「自動化ポリシー」を探します。
自動化ポリシーとは、あるイベントがコマンドの実行を引き起こすシナリオです。
コマンドがなんらかの判定条件を満たした場合にのみ実行されるんら、その判定条件も明記します。
#### Step7 : 読み取りモデルを見つける
読み取りモデルは、アクターが、コマンドを実行するかどうかを判断するために使う、対象領域の状態を表現するデータのビューです。
画面、レポート、通知などが該当します。
#### Step8 : 外部システムを追加する
このステップでは、外部システムを追加してモデルを拡張します。
外部システムとは、探求している業務領域の外側に存在するシステムの表現です。
コマンドを実行したり、イベントに関する通知を受けたりする可能性があるものが該当します。
このステップが終わった段階で、全てのコマンドは、
- アクターによって実行されるか
- ポリシーによって発動されるか
- 外部システムによって呼び出されるか
のいずれかになっているはずです。
#### Step9 : 集約を見つける
全てのイベントとコマンドを洗い出したら、関連する概念を集約として整理します。
集約はコマンドを受け取り、イベントを生成します。
#### Step10 : 区切られた文脈に分割する
イベントストーミングセクションの最後のステップとして、機能的に密接に関係していたり、自動化ポリシーを介して結合されていたりする集約を探します。
このような集約の集まりが、**区切られた文脈**の境界の自然な候補となります。
</イベントストーミングの手順>
<指示事項>
この手順を用いて、以下のような業務に関し、イベントストーミングの手順に沿って分析を行い、業務フローを出力してください。
まずはStep1からお願いします。
</指示事項>
<対象業務>
とある会員制のストリーミングサービスでは会員を増やし、かつより単価の高いプレミアム会員への移行を促進するために色々な改善施策を行っています。
改善施策は、ビジネスオーナーが発案したり、協業先（代理店）から提案されたりします。
改善施策は、その実行可能性や費用対効果、法令への遵守度、アプリの利用規約への適合度などを検討し、実施するかどうかを決定します。
実施するかどうかについては、リスクや投入する費用に応じて、ビジネスオーナーの判断で実行される場合もあれば、より上位の組織による承認が必要な場合もあります。
いずれの場合にも、実行の承認、条件付き承認、却下などの結果が発生します。
なお、同社はコンプライアンスを重視しており、利用規約の改定の可能性がある場合には、法務部に相談します。
利用規約改定が必要と認められた場合には、利用規約の改定と会員からの改めて同意を得る必要があります。
実行の承認が得られた場合には、開発チームに要件定義が引き渡され、開発チームは要件定義をもとに実装を行います。
条件付き承認の場合には、条件をクリアするべく再度フィージビリティースタディが行われ、その結果がビジネスオーナーに報告されます。
この結果実行がの承認が得られる場合もありますが、却下される場合もあります。
開発チームが要件定義を元に、設計を行い、実装が完了したならば、ビジネスオーナーによるリリース判定が行われます。
リリース判定の結果についても、承認、条件付き承認、却下のいずれかが発生します。
現実的には、却下されることはほとんどなく、条件付き承認やリリースの延期という形になります。
最後に、改善施策については、意図通りの効果が得られたかどうかを評価し、今後の施策に活かすためのフィードバックを行います。
例外的に、外部システムやインフラストラクチャーの更改にともなって、開発作業が発生する場合もあります。
</対象業務>
</task>
Clineと作った成果物！
概略フローを提示します。
詳細フロー
かなり長いので、GitHubを見てください！
まとめ
書籍にあるように、イベントストーミングは本来、できればアナログなやり方で対面実施するのが良いと思います。
しかし、現実問題としてロケーションが離れている場合など、デジタルを使ってやらざるを得ない場合が多いと思います。
その際には、デジタルのホワイトボードなどでフローを描画する方法もありますが、AIエージェントとの対話を通じて思考を深めていくのも有効であると思いました。
有効な点
- 言語化の過程で同じ言葉（ユビキタス言語） を使うようになる
- 議論（AIエージェントとのやりとり）のログをエクスポートできるためトレーサビリティーが高い
- 成果物がMarkdownやMermeid形式で残るためそこから関連文書やコードの自動生成に繋げやすい
気をつけないといけない点
- 本来の方式に比べると発散が不十分になり、例外的なフローや改善の機会を見失うリスクがある
- ドメインエキスパートが生成AIに慣れていないと積極的な参加が得られない可能性がある
今後のwithAI時代の開発に向けて少しでも参考になれば幸いです。
おまけ
今年は、アドベントカレンダーの記事を3本書くことになりました。
過去の2本の記事も紹介しておきます。