ビジネスプロセスモデリング
ビッグピクチャーで洗い出したイベント群に、コマンド、集約、外部システム、ポリシーといった要素を加え、異なるイベントをつなぐメカニズムを明らかにしていきます。
たとえばECサイトの「注文が確定された」と「支払いが行われた」という2つのイベントの間には、決済システムとの連携や在庫確認といった重要な処理が存在し、このフェーズではそうした処理の詳細や条件を明確にしていきます。
さらにリードモデルとアクターを導入すると、誰がどのような判断や操作を行うのか、どのようなルールにもとづいて処理が進むのかという観点が加わり、開発者とビジネスを結び付ける設計図へと発展していきます。
イベントとイベントをつなぐルール
イベント単体では次のイベントを引き起こしません。イベント間のつながりにはポリシーのような仲介役が必要です。
イベント同士のつながり方のルールは次の図3のとおりです。
図3を見るとわかるとおり、イベントからイベントにつなげるためのルートには大きく2つのパターンがあります。ポリシーが仲介するルートと、リードモデルとアクターが仲介するルートです。この記事では便宜的に、前者をポリシールート、後者をリードモデルルートと呼ぶことにします。
ポリシールートは「イベント→ポリシー→コマンド→集約または外部システム→イベント」と進みます。たとえば「注文が確定された」というイベントが発生したとします。「注文が確定されたら在庫を予約する」というポリシーが働き、「在庫を予約する」コマンドが発行されます。これが在庫集約で処理された結果、「在庫が予約された」イベントが発生します。
リードモデルルートは「イベント→リードモデル→アクター→コマンド→集約または外部システム→イベント」と進みます。「商品が返品された」というイベントが発生すると、それがリードモデルに反映され、カスタマーサービス担当者（アクター）がそれを確認します。担当者が「返金処理コマンド」を実行し、決済システム（外部システム）による処理の結果として「返金が完了した」イベントが発生します。
ポリシールート
ポリシールートではアクターの判断を挟まず、ポリシーが次のコマンドを発行して処理をつなぎます（図4）。コマンド・集約・外部システム・ポリシーの4要素がそれぞれどんな役割を担うかが論点になります。
ポリシー・コマンド・集約または外部システム・イベントのセットはイベントストーミングの中で頻出します。ホワイトボードツールなどを活用している場合は基本セットとして付箋テンプレートを事前に準備し、コピーして使い回せるようにしておくと、付箋を作る作業に気を取られず議論に集中できます。
コマンド
イベントの多くは誰かが何かを意図した操作をきっかけに発生します。このきっかけを表すのがコマンドです。
コマンドはイベントと対になる動作（動詞）として書きます。たとえば「注文された」というイベントがあるなら、コマンドは「注文をする」といった具合です。
しかし、必ずしもイベントとコマンドの言葉が現在形と過去形で一対一で対応するわけではありません。たとえば「クーポンを利用する」というコマンドに対して、「割引が適用された」というイベントが発生する場合があります。コマンドは何をしたいか、イベントはその結果何が起きたかを表すため、単に同じ言葉を現在形から過去形に変えた名前になるとは限りません。
集約
コマンドとイベントを直接つなぐことはできません。システム内部では、その間に集約が挟まります。集約はコマンドを受け取り、処理を実行し、その結果としてイベントを発生させます。
たとえば「注文をする」コマンドと「注文された」イベントの間には、書籍の第4章で紹介するOrder集約のように、それらを処理する「注文」集約を配置します。
標準的なイベントストーミングでは後の段階で集約の付箋を配置するようですが、私はビジネスプロセスモデリングの時点で配置してしまうことが多いです。集約を早期に配置しておくことで後の付箋の移動を最小限に抑えられるからです。
集約の命名は名詞で行いますが、このフェーズでの命名は暫定的なものです。実際このタイミングで適切な名前を決めることは難しく、私のやり方ではたいてい無名の集約のままにしておきます。これは集約を捉えることはそもそもシステム設計側の作業であり、全体のビジネスフローが見えてから集約を見直すほうが、より適切な命名ができるためです。
外部システム
外部システムは、私たちの管理範囲外でありながら、ビジネスプロセスに直接影響を与える要素です。他チームが管理するシステムやサードパーティのサービスがこれにあたります。図では外部システムにもコマンドをつなぎ、その処理結果をイベントとして描きます。
注文システムでは外部の決済事業者が提供する「決済サービス」との連携が発生します。決済サービスは「支払いを実行する」コマンドを受け付け、「支払いが行われた」イベントを発行します。他チームが管理する在庫システムや配送システムと連携する構成であれば、それらも同じように外部システムとして描きます。
なお、同じ在庫や配送でも、自分たちで実装するなら集約の付箋になり、他チームや外部事業者に任せるなら外部システムの付箋になります。どちらとして描くかを決めることは、どこまでを自分たちで作るのかを決めることと同じです。また、自分たちの持ち物であっても、今議論しているコンテキストの外にあるシステムは外部システムとして表すことがあります。
外部システムに関連するイベントの扱いには注意が必要です。記録するのは、自社システムの状態に影響を与えるものや、アクターの行動に関わるもの、ビジネス上重要な意味を持つものです。
一方で、外部システムの内部処理に関するイベントは記録しないことがほとんどです。たとえば決済サービスの「取引IDを生成した」といった中間状態は、通常記録する必要はありません。記録すべきは最終的な結果である「決済が行われた」というイベントです。
ポリシー
ポリシーはイベントとコマンドを結び付ける要素です。ポリシーは特定のイベントが発生した際に自動的に特定のコマンドが実行されるような規則を表します。注文システムの例では「支払いが行われた」イベントが発生すると「出荷を指示する」コマンドが実行される、といった規則がポリシーとして定義されます。
ポリシーは条件付きのルールも表現できます。たとえば高額の注文にだけ承認を挟みたいなら、「注文金額が10万円以上」という条件を書いたポリシーを置き、そこから「承認を要求する」コマンドへつなぎます。条件はポリシーの付箋にそのまま明記します。逆に何も書いていない空白のポリシーは、イベントを受け取ったら常に次のコマンドを発行することを表します（図5）。
複数のイベントから同じコマンドを実行したい場合もあります。たとえば「支払いが行われた」と「後払いが承認された」という異なるイベントのどちらからでも「出荷を指示する」コマンドへ進めたい場合、それぞれのイベントからポリシーを通じてコマンドへ合流させられます。
このときポリシーをひとつにまとめて、2つのイベントから矢印を集める構成にはしません。ポリシーに入る矢印は常に1本です。ポリシーは「このイベントが起きたら」という規則の単位なので、反応するイベントごとに1枚置き、合流はコマンドハンドラで受けます。
なおポリシーには名前を付けることもできますが（「支払い完了ポリシー」など）、実用上はあまり意味を持たないため、私は基本的に名前を付けずに運用しています。
この記事は参考になりましたか？
- 翔泳社の本連載記事一覧
-
- 認識がそろうチームほど「決めないこと」を書き残す イベントストーミングが議論の熱量に流され...
- このままでいいのかとざわめく心に問いかける 壁にぶつかるエンジニアに届けたいこの思い
- まじめに働きたい気持ちがエンジニアを追い詰める 職場の不機嫌が脳をバグらせる理由
【AD】本記事の内容は記事掲載開始時点のものです 企画・制作 株式会社翔泳社
この記事は参考になりましたか？
この記事をシェア
