はじめに
コンテナ技術の進展に伴って、ビジネス環境の変化に迅速に対応できるマイクロサービスに関心が集まっています。最近では、マイクロサービスを分割する方法の一つとしてドメイン駆動設計が注目されています。ドメイン駆動設計では、業務に精通した方々や技術者が、モデリングなどいろいろな技法や専門用語を使い、それらを理解した上で設計を進めていきます。様々なステークホルダーとチームを組んで一緒に取り組むにしても、直観的にはとてもわかりづらいと感じています。そこで、いろいろと記事を調べてみたり、身近な技術者と意見交換をしたところ、イベントストーミングという手法がありました。イベントストーミングに関する記事は他の記事に比べあまり多くはないので、この場で共有しておきたいと思い掲載することにしました。これからドメイン駆動設計をはじめるという方や、既に取り組んでいるけれど進め方に悩んでいる方など、参考になれば幸いです。
マイクロサービスとドメイン駆動設計
国内において徐々にデジタルトランスフォーメーション（DX）への取り組みが広がるにつれ、それぞれの企業は、ビジネス環境の変化に迅速に対応することに高い関心を寄せています。ビジネスのアジリティ（俊敏性、変化対応力）を実現するためには、ビジネスの一端を担う情報システムも柔軟に対応できる構造でなければならないといわれています。
そもそも、情報システムには、品質や堅牢性を求められるSoR領域、新しいアイデアを実現するためにトライ＆エラーを繰り返し変化し続けるSoE領域やSoI領域があります。そこで、それらを適切に分割し、独立性、柔軟性、拡張性が充分に確保できるシステム構造を実現するのが、分散・疎結合なアーキテクチャ、いわゆるマイクロサービスアーキテクチャなのではないでしょうか。前回の記事では、マイクロサービスアーキテクチャでは、適切にドメインを分割する手法の一つとしてドメイン駆動設計（Domain-driven design, 以下 DDD）が有効ではないかと考えてみました。
DDDでは、業務を熟知しているドメインの専門家（ドメインエキスパート）とソフトウェアの専門家（アーキテクトや開発者）が一緒に業務のモデル（ドメインモデル）を作成します。そして、ドメインモデルをコードに変換しながら、ドメインモデルとコードを相互にブラッシュアップしていきます。そうすることで、ドメインの専門家とソフトウェアの専門家の乖離をなくすことができるとしています。このように、DDDの手法を用いることで、適切にドメインを分割しマイクロサービス化が実現できそうです。ただし、現実的にはそう簡単にはいかないようです。
ドメインを分割するうえでの様々な障壁
DDDでは、開発者がシステム化する対象のドメインを深く理解するためには、ドメインエキスパートの参画を必要としています。しかし、現実的には、以下のような様々な障壁があります。
- ドメインエキスパートの不在
ドメインエキスパートには本来行うべき業務を遂行することが求められるため、時間的な制約があります。限られた時間の中で情報を収集しなければなりません。 - 断片的なドメインの知識
ドメインエキスパートが把握しているドメインの知識は、把握している一部の領域にとどまります。ドメイン全体を理解するには、それぞれのドメインエキスパートの知識を得なければなりません。 - モデリング技法の理解不足
UMLなどモデルの表記法によっては、ドメインエキスパートの理解が及ばないことがあります。ドメインの知識はステークホルダーで正しく共有されなければなりません。
実際のビジネスでは、いくつものドメインがあり、それらが複雑に相互依存して互いに影響を与えます。それらのドメインに存在する重要な問題やボトルネックを発見するためには、先程述べた障壁を取り除き、複雑なビジネスプロセスを明らかにしていくことが不可欠です。
それを実現する方法の一つとして、イベントストーミングというモデリング手法があります。
イベントストーミングとは
イベントストーミング（Event Storming）は、Alberto Brandolini 氏が提唱したワークショップ形式のモデリング手法です。この手法は、ドメインで発生するイベント（ドメインイベント）を深く理解することに重点を置き、関連するすべてのイベントをタイムラインに沿って配置することで、複雑なビジネスプロセス全体を明らかにし、問題領域を特定することができます。
先に述べた障壁を取り除く効果はそれぞれ次のとおりです。
- ワークショップ形式による集中討議
ドメインエキスパートや開発者が参加するワークショップ形式の集中討議により、ドメインに関する共通の理解をワークショップ期間中の限られた時間で実現できます。 - 関係するドメインエキスパートの参画
すべてのシナリオがカバーされるまで繰り返すことで、関係するドメインエキスパートが参画する機会を与え、ドメイン全体について参加者の理解を促すことができます。 - 誰でもすぐに参加できる簡単な表記法
特定の表記法（UML、ER図など）を参照していた従来のモデリング技法とは異なり、付箋紙を使った簡単な表記法を利用することにより、参加者全員が積極的にディスカッションに参加できます。
DDDにおけるイベントストーミングの対象フェーズ
イベントストーミングは、「実践ドメイン駆動設計」 で示されている戦略的設計と戦術的設計の２フェーズ（戦略フェーズ／戦術フェーズ）のうち、戦略フェーズにあたります。
イベントストーミングの進め方
イベントストーミングでは、対象となるドメインに関係する異なる経歴を持つ人たちが協力して、1つ以上のビジネス・プロセスをモデル化していきます。ワークショップには、次のような人たちが参加します。そして、ワークショップ期間中に、これらの人たちが参加できる機会を設けます。
ワークショップの参加者
- ファシリテータ
ワークショップの組織と運営に責任を持つ人です。ファシリテータは、参加者をイベントソーシングの実践について案内し、議題を管理することで、セッションの最良の成果を生み出すことができます。 - ドメインエキスパート
ビジネス領域の様々な業務に携わり、業務の深い洞察力を持っている人たちです。これらの人たちは、「何を」（What）、「なぜ」（Why）を表現することに注力します。 - 開発チーム／技術エキスパート
システムの設計と開発を担当するチームです。 これらの人たちは、「何を」（What）と「なぜ」（Why）をよりよく理解し、 次の戦術フェーズ（どのように実装するか）につなげるための理解を深めます。
ワークショップのモデル表記法
ワークショップでは、書きこみ可能な大きな壁（ボード）一面に付箋紙を貼ってモデルを表現していきます。モデリングに使用する付箋紙は、それぞれ色によって意味づけされています。
さらに、それぞれの付箋紙には、次のような関係があります。
ワークショップを実施する前に、ワークショップの参加者がこれらの基本的な定義を理解していることを確認し、言葉をシンプルにし、不必要な専門用語を使わないようにします。
ワークショップの概要
「EventStorming」（Alberto Brandolini）では、ワークショップの実施にあたり、キックオフからクロージングまでいくつかのフェーズに分かれています。それらのフェーズは、わかりやすく要約すると４つのステップで表すことができます。ワークショップでは、次の４つのステップで実施します。
ステップ１：ドメインイベントと外部システムを抽出する
このステップでは、タイムライン全体にドメインイベントと外部システムを配置します。そして、ドメインイベントと外部システムを横のタイムラインに並べていくことに重点を置きます。ここでは、コマンド、ユーザの役割、その他の要素を含むフローの詳細を深く掘り下げないようにします。もし、それらのアイテム（ステップ１の範囲外のアイテム）が発生したら、適切な付箋紙を作成し、次のステップで検討するアイテムとして配置するボード（Future Placement Board）に置いておきます。 複数のシナリオが存在する場合は、次のステップ２に進む前に、タイムラインに付箋を繰り返し追加します。
ステップ２：イベントとシステム間のギャップを埋めてフローを作成する
このステップでは、コマンド、ユーザの役割、方針などを追加して、ドメインイベントと外部システム間のギャップを埋め、フローを作成します。前のステップ１のドメインイベントおよび外部システムに関連する要素をさらに記述します。前のステップ１で置いてあったボード（Future Placement Board）のアイテムから始めていきます。
ステップ３：集約を抽出する
このステップでは、前のステップ２で作成したフローから集約を抽出します。 集約には、コマンドが処理できるデータを表します。集約は、1つ以上のエンティティの整合性を保つことができる境界を定義します。集約は、ドメインイベントをサポートするために不可欠なデータの表現であり、コマンドが動作できる要素です。集約の命名を適切に行えば、コンテキストの議論に移るときに役立ちます。
ステップ４：境界づけられたコンテキストを定義する
このステップでは、集約、操作するデータ、コンテキストに基づいてボードをソートします。 集約の間に共通の基盤がある場合は、それらの間の依存性のレベルが高い可能性があるため、それらを同じコンテキストに配置することを検討し、コンテキストの境界を決定します。そのように境界づけられたコンテキスト間の関係を追加して、コンテキストマップを作成します。
ワークショプの参加者は、これらのステップに沿って進めていきます。ドメインイベントと外部システムの抽出から始まり、タイムラインに沿って配置されたドメインイベントと外部システムを前後にウォークスルーして、すべてのドメインイベントがカバーされていることを確認します（ステップ１）。そして、参加者は、ドメインイベントを発生させるコマンドまたはトリガを追加し、ユーザーの役割、および時間によって起動されるアクションを含むすべてのコマンドを明らかにしていきます（ステップ２）。さらには、コマンドを受け入れてイベントを実行する集約を識別し、集約をグループ化していきます（ステップ３）。その過程で、主要なテストシナリオ、ユーザー、および目標を特定し、モデルに組み込んでいきます。最後に、境界づけられたコンテキスト間の関係を追加してコンテキストマップを作成します（ステップ４）。
さいごに
ドメイン駆動設計に役立つイベントストーミングについて紹介しました。いかがでしたでしょうか。経験上、ドメイン駆動設計では、専門用語や技法、プロセスがあり、それらを理解し実行できるようになるまでに多くの時間を費やしました。従来のモデリング技法を使って進めるなど様々な方法はありますが、それと同時に、ドメインエキスパートや技術者など、様々なステークホルダーにとって障壁があることも事実です。それに対して、イベントストーミングでは、ワークショップ形式で付箋紙を使った簡単な表記法を利用するので、特定のモデリング技法を習得していなくても、様々なステークホルダーの全員が参加する機会を設け、積極的にディスカッションすることができるのではないでしょうか。それにより、参加者のさまざまな専門知識や視点を結集し、組織構造や目的、仕組み、そして問題領域についてより深く認識することができるでしょう。
※掲載内容は私個人の見解であり、所属する組織の公式見解ではありません。
参考文献・参考記事
- Introducing EventStorming（Leanpub）
- EventStorming（外部リンク）
- エリック・エヴァンスのドメイン駆動設計（翔泳社）
- 実践ドメイン駆動設計（翔泳社）