TL;DR
- ビジネスの価値はデータを変換する過程で生まれるので、データ構造よりもビジネスイベントやワークフローに焦点を当てる。
- ドメインイベントは、モデル化したいほとんどすべてのビジネスプロセスの出発点になる。イベントストーミングで洗い出し、それを引き起こすコマンドも記録する。
内容
ドメインイベント
ビジネスは単にデータを持っているだけでなく、何らかの方法でデータを変換している。ビジネスの価値はこの変換の過程で生み出される。そのため、変換がどのように機能し、互いにどう関係しているかを理解することが重要である。
逆に、使われずに放置されているデータは何の役にも立たない。データに価値が加わるきっかけをドメインイベントと呼ぶ。きっかけには、外部からのトリガー（郵便物が届いた、電話が鳴った）、時間に基づくトリガー（午前 10 時になった）、観察（処理すべき注文が受信箱からなくなった）がある。
ドメインイベントは設計の一部として表現する。ドメインイベントは常に過去形で書き、変更できない事実である。そのため、モデル化したいほとんどすべてのビジネスプロセスの出発点になる。
イベントストーミングによるドメインの探索
イベントストーミングは、ドメインイベントを発見する方法の 1 つである。ドメインのさまざまな部分を理解している人を集め、進行役のもとでワークショップを行う。参加者には開発者やドメインエキスパートだけでなく、プロジェクトの成功に関心のあるすべての関係者を含める。よく言われるのは「質問のある人と、答えられる人」である。
ワークショップでは、ビジネスイベントを付箋に書き出して壁に貼っていく。それを見た他の人が、そのイベントをきっかけとするビジネスワークフロー（「注文する」「発送する」など）を付箋に書いて貼る。さらに、そのワークフローがきっかけで別のビジネスイベントが生まれることもある。付箋を時系列に並べると、議論が深まることもある。参加者は自分が知っていることを壁に貼り、知らないことは質問する。
イベントストーミングを行うと、次のことが進む。
- ビジネスの共通モデル: 参加者がビジネスについて共通の理解を深められる
- 全チームの把握
- 要件の抜けの発見
- チーム間の連携: 各チームが具体的にどう連携しているかが分かる
- レポートの要件: レポートのように読み取られるだけのモデルもドメインの一部である
イベントを端まで広げる
イベントの連鎖をシステムの境界まで可能な限り追うと、足りない要件を見つけられる。このとき、デジタルでどう実現するかは考えず、ドメインを理解することに集中する。多くのビジネスプロセスでは、紙とデジタルの区別は関係ない。また、システム化するときに一度にすべてを移行する必要もない。最も効果が期待できる部分から着手するべきである。
コマンドの文書化
ドメインイベントをいくつか壁に貼ったら、「これらのドメインイベントを引き起こすのは何か」を尋ねる。これが DDD におけるコマンドである。ドメインイベントが過去形なのに対し、コマンドは常に現在形（「〜する」）で書く。たとえば「顧客が注文書を受け取る」「上司が指示する」などである。ただし、すべてのイベントがコマンドと結び付く必要はない。会計システムの月末締めや倉庫システムの在庫切れのように、スケジューラや監視システムがトリガーになるものもある。
コマンドは必ず成功するわけではない。失敗は別にモデリングする（第10章 Implementation: Working with Errors）。コマンドが成功するとワークフローが始まり、対応するドメインイベントが作られる。作られたドメインイベントが、別のコマンドのトリガーになることもある。
コマンドが「〇〇する」なら、ワークフローが〇〇をしたあとのドメインイベントは「〇〇した」または「〇〇された」になる。たとえば、コマンド「Widgets Inc. に注文書を送信する」に対するイベントは「注文書が送信された」、コマンド「注文を確定する」に対するイベントは「注文が確定された」、コマンド「顧客 A に発送する」に対するイベントは「発送された」である。
このように、ビジネスプロセスを入力と出力を持つパイプラインとして考える方法は、関数型プログラミングの仕組みと相性が良い。本書では、以降ほとんどのビジネスプロセスをこの方法でモデリングする。
キーワード
自分の理解
コマンドの失敗のモデリングでは、モナドなどが出てくるのだろうか。