ビジネスイベントを通じてドメインを理解する
データ構造よりも、ビジネスイベントやワークフローに焦点を当てる
このアプローチを行うのは、ビジネスは単にデータを持っているだけでなく、何らかの方法でデータを変換するからである。
ビジネスの価値は、この変換の過程で生み出される
そのため、これらの変換がどのように機能して互いにどのように関係しているかを理解することが重要
逆に、使われずに放置されているデータは何の役にも立たない。
このようなデータが価値を付加されるきっかけ（ドメインイベント）は、外部からのトリガーや時間に基づくトリガー、観察である 外部からのトリガー: 郵便物が届いた、電話が鳴った
時間に基づくトリガー: 午前 10 時になった
観察: 処理すべき注文が受信箱から無くなった
このドメインイベントを設計の一部として表現することが重要である
ドメインイベントは常に過去形であり、変更できない事実である
そのため、ドメインイベントはモデル化したいほとんどすべてのビジネスプロセスの出発点となる
イベントストーミングによるドメインの探索
様々な人（ドメインの様々な部分を理解している人）を集めた進行役つきのワークショップ
参加者は、開発者やドメインエキスパートだけでなく、プロジェクトの成功に関心のあるすべての関係者を含めるべき
よく言われるのは、「質問のある人と、答えられる人」
ワークショップではビジネスイベントを付箋に書き出し、壁に貼っていく
https://scrapbox.io/files/6683474c288f1b001dc1c1e1.png
それを見た他の人が、その出来事をきっかけとしたビジネスワークフローをまとめたメモを貼る 上記の画像の Place Order や Ship Order が該当
更にそのワークフローがきっかけで、別のビジネスイベントが生まれることもある
付箋を時系列に整理することで、グループ内での議論が深まることもある
参加者全員が知っていることを壁に貼り、知らないことは質問する
イベントストーミングをすることで、以下のことが促進される。
ビジネスの共通モデル: 参加者がビジネスに対する共通の理解を深められる
全チームの把握
要件のギャップの発見
チーム間の連携: 各チームが具体的にどう連携しているか
レポーティング要件: レポートのような読み取られるだけのモデルもドメインの一部 イベントを端まで広げる
イベントの連鎖をシステムの境界まで可能な限り追跡することで、不足している要件を見つけることができる。
https://scrapbox.io/files/6683807e287c89001cd924d6.png
このときデジタルでどう実現することは考えない
ドメインを理解することに集中する
多くのビジネスプロセスでは、紙とデジタルの区別は関係ない
システム化する際、一度にすべて移行する必要もない
最も効果が期待できる部分から着手すべき
コマンドの文書化
ドメインイベントを壁にいくつか貼ったら、「これらのドメインイベントを引き起こすのは何か」を尋ねる。
コマンドは常に現在形（「◯◯する」）である
ドメインイベントは過去形
e.g. 顧客が注文書を受け取る、上司が指示をする
ただし、すべてのイベントがコマンドと関連付けられる必要はない
スケジューラや監視システムによってトリガーされるもの
e.g. 会計システムの月末締めや倉庫システムの在庫切れ
コマンドは必ず成功するわけではない
ここで モナド とか出てくるのかな？radish-miyazaki.icon https://scrapbox.io/files/668383067a07ad001c6621b5.png
作成されたドメインイベントが別のコマンドのトリガーとなる場合もある
このようにビジネスプロセスを「入力と出力を持つパイプライン」として考える方法は、FP の仕組みとマッチしている。 コマンドが「〇〇する」だった場合、ワークフローが〇〇をすれば、対応するドメインイベントは「〇〇した」または「〇〇された」となる
具体例
コマンドが「Widgets Inc. に注文書を送信する」だった場合、ワークフローが注文を送信すると、対応するドメインイベントは「注文書が送信された」
コマンド「注文を確定する」に対するドメインイベントは「注文が確定された」
コマンド「顧客 A に発送する」に対するドメインイベントは「発送された」
https://scrapbox.io/files/6683863acf0eb6001dc3e51d.png
以降、ほとんどのビジネスプロセスをこの方法でモデリングする