■ 1. イベントストーミングの基礎
- 目的: イベントを起点として、ビジネスプロセスやシステムのモデリングを行う手法である。
- 構成要素:
- アクター: コマンドを実行する主体である。
- コマンド: 何らかのアクションを実行する意図や要求である。
- 集約: コマンドを処理するオブジェクトである。
- イベント: ビジネス上で発生した重要な出来事や事実である。
- リードモデル: データの読み取りに最適化されたデータ構造やビューである。
- ポリシー: 自動化された判断ロジックであり、nrs流では条件を空欄にして「必ず」を意味させる。
- 外部システム: 対象システムの境界外にあるシステムである。
- ルール:
- 付箋は特定の付箋からしか繋げられない。
- 複数のイベントは結果の分岐や並列に起きる出来事を表す。
- 実践方法:
- ワーキングセッション: メンバー全員が理解した上で取り組む。一気に進むが、経験がないと難しく、長時間かかる。
- ヒアリング: ファシリテーターがヒアリングを進める。短時間でまとまりやすいが、ファシリテーターの技量に依存する。
■ 2. イベントストーミング図からコードへの変換
- 変換の前提: 今回のセッションでは、イベントストーミング図をトランザクションスクリプト、ドメインオブジェクト、複合パターン、バッチ処理といったコードに変換する。
- 単純な処理: アクターからコマンドが投げられ、リードモデルに繋がるパターンは、コントローラーとアプリケーションサービスで実装する。
- ポリシーが絡む処理: コマンドの実行中に条件分岐が発生する場合（例：写真が同時にアップロードされた場合）、アプリケーションサービス内でポリシーとして実装する。
- 外部システムとイベントの分岐: 決済処理のように外部システムとの連携と、その結果（成功/失敗）によってイベントが分岐するパターンは、アプリケーションサービス内で外部サービスを呼び出し、結果に応じて異なる処理を行う。
- バッチ処理: 一括で大量のデータを処理するバッチ処理も、イベントストーミングのパターンとして表現できる。
■ 3. イベントストーミング図の活用と注意点
- 図の目的: 図はすべての情報を表現することが目的ではなく、実装に役立つドキュメントとして活用すべきである。
- 図の種類:
- ビジネスプロセスモデリング: ビジネスの流れを可視化する。
- システムモデリング: より実装に即した設計を行う。
- コードとの一致: 図とコードを完全に一致させたい場合は、イベントソーシングのような手法を適用する必要がある。