はじめに
システムのリアーキテクチャや新規サービスを開発するときに、業務知識の俗人化や人が入れ替わる度にキャッチアップのために多くの時間を割くの嫌ですよね。
今回はイベントストーミングによるモデリングとDDDで設計して、コードに落とすとこまで、紹介したいと思います。
イベントストーミングとは
複雑なビジネスプロセスやドメインの全体像をチームで視覚的に理解し、システム設計に活かすための手法です。
従来の手法と違って、ドメインに詳しい人とエンジニアが集まって、行うことで、要件の漏れを防ぎやすくなったり、チーム全員に理解を促すことができます。
また、モデルとソースをマッピングすることで、仕様変更時や数年後アーキテクチャを変更する場合も影響範囲を把握しやすくなります。
イベントストーミング要素
・アクター
コマンドを実行する人やシステム
・コマンド
ユーザやシステムが実行するリクエスト
以下のことをルールとして決めるとよい。
- 過去形動詞を使用する。
- 専門用語を使用しない
・集約
関連するデータやエンティティの集合体
・外部システム
S3、SendGridなど利用する外部システム
・イベント
発生した事象やアクション
・ポリシー
イベント発生の条件やルール
・ビュー/リードモデル
ユーザへ返却するデータを表現
・ホットスポット
注意が必要な事柄
各要素の概要は以上のとおり。
イベントストーミングフロー
ビッグピクチャ
目的: システムやドメイン全体の理解を深め、チーム間の共通認識を作る。
範囲: 全体のプロセスの流れ、エンドツーエンドの視点
実施内容:
・イベントを思いつく限り列挙する
・イベントをカテゴライズする
・イベントを時系列に並べる
プロセスモデリング
目的: ビジネスプロセスや業務フローの詳細な理解と設計
範囲: 特定のビジネスプロセスや機能に絞り込み、その詳細な流れを把握
実施内容:
・アクターとコマンドを追加する
・外部システムを追加する
・アクターから実行されないコマンドはポリシーとして出す
・アクターへ返却するデータをリードモデルとして出す
ソフトウェアモデリング
目的: システム内でのイベント処理フローの詳細化
範囲: データの流れやイベントの発生から処理までの流れ
実施内容:
・集約の特定
・境界の定義
集約は整合性を保つための単位です。
境界とは特定のモデルが定義される粒度
この辺は言葉での表現だと分かりづらいので、モデリングの例を見ていただけるとイメージつくかなと思います。
実践
お題は出前サービスとします。
私自身はドメイン詳しいわけではないので、業務が間違っている可能性があります。
また例題のため、細かく業務を洗い出しません
- 思いつくイベントを挙げていく
2.イベントをカテゴライズしながら時系列で並べていく
3.プロセスを詳細化しつつ、不足しているプロセスを追加する
4.コメントや懸念事項があれば追加（すみません、先に集約入れてしまってます）
5.集約を特定
6.境界の定義
さいごに
一連の流れを掴めたかなと。
ただ、何回やっても集約と境界の定義が難しいなと感じます。
いきなりベストな解は出ないかなと思うので、コード書きつつ修正の繰り返しになると思うので、ひとまず参加者の半数の承諾得られたら仮決めという形で次へ進んでいいと思います。
次はこの図からドメインモデルを作成していきます。