Event Modeling Projectは、時間とイベントの概念をシステムを説明するためのコアコンセプトとして使用することにより、システム設計にアプローチする新しい方法を提唱している。プロジェクトによって提案された言語/構成は、組織内の役割の可能な最大の断面にわたってシステムがどのように機能するかを伝えることを目的とする。このプロジェクトの目的は、イベントをアーキテクチャの中心に据えたアプリケーションを開発したいアプリケーションに、明確で反復可能なモデリングパターンを提供することである。
Event Modeling Project全体の詳細については、InfoQは、Event Modelingの創設者でありAdaptechGroupのCEO兼創設者であるAdam Dymitruk氏と話をした。
InfoQ: Adam、ご参加いただきありがとうございます。では、どのようにして最初にEvent Modelingに取り組み始めたのですか ?
Adam Dymitruk氏:
Event Modelingは、ソフトウェア開発を - 特に企業で - 工学分野のようにする必要性から生まれました。厄介な情報システムを設計および構築するための唯一の「適切な」方法としての、RUPおよびUMLに対する問題が提起されたとき、業界はアジャイルを代わりにして設計をあきらめました。これは多くの損害を引き起こしました。正解は、システムを設計することでしたが、UML、RUP、および関連するプラクティスのように高価な方法で設計することはしませんでした。状態とユーザエクスペリエンスについて正しく効率的にコラボレーションすることにより、以前の面倒な試みまたは表面的な試みのいずれかで発生したソフトウェア開発のすべての問題が解消されました。これで、工学分野のような効果的な青写真ができました。
もう1つの動機は、課せられたプロセスや方法論に対して人間の心が自然に機能する方法を利用する必要があることでした。つまりストーリーとして受け入れることです。イベントモデルを左から右に解釈すると、映画のストーリーボードによく似たストーリーが得られます。それは、私たちが物事を最もよく覚えている方法に非常によく似ています。下はプロットで、上はシーンのキーフレームです。
コラボレーションも、業界では十分に効果的に行われていなかったものでした。Event Modelingを使用すると、組織内の複数の役割の人々がシステムについて共同作業を行うことができます。したがって、これには、特定の役割を他の役割よりも優先しない、単純で共通の要素のセットが必要でした。
InfoQ: Event Modelingは、従来のシステム設計のアプローチとどのように比較されますか ?
Dymitruk氏:
Event Modelingは、従来のシステム設計分野では示されていない非常に重要なショートカットを示します。Event Modelingにより、システムの「実装方法」を説明する必要がなくなります。クラスやメソッドを示す図は見つかりません。いくつかの類似点はあります。これを「システム全体の水平シーケンス図」と呼ぶ人もいます。Event Modelingの水平スイムレーンは、シーケンス図の垂直クラスインスタンスラインのように見えます。しかし、それが類似点はそれだけです。
Event modelingにより:
- ワークフローのロジックに分岐はありません。 これにより、ストーリーの考え方を維持できます。
- クラスやメソッドのような技術的な実装アーティファクトはありません。
- 信頼できる情報源としてのイベントに焦点を当てます。イベントが実装に含まれるかどうかは、実装次第です。
- 情報とワークフローは、クラスやシステムの境界、または他のIT固有の概念とは対照的に、他の概念が依存するアンカーです。
- レポートの目的で、同じデータの複数のモデルが自動的に作成されます。これは、エンティティ関連図で使用されている第3正規形とは大きく異なります。
- これは、ページ、図、またはその他のアーティファクトのコレクションではなく、1つの青写真です。これにより、いつでも必要なものを簡単に見つけることができます。
- UX/UIが主な関心事です。画面は、分析的ではなく視覚的である人々のニーズにも対応するため、システムの中核部分です。
InfoQ: 従来のアプローチと比較したEvent Modelingのビジネス上および技術上の利点を簡単に説明できますか ?
Dymitruk氏:
Event Modelingには、独立した作業単位 (スライス) が含まれています。これにより、スタンドアップ、スプリント、およびリモートワークでは効果的でない他の多くのプロセスを必要としません。これらの節約された時間は、ソリューションの実装に取り組むために再投資されます。リモートワークへの移行は、Event Modelingがもたらすガイダンスでは感じられません。
パターンが規定されているため、Event Modelingは、ソフトウェア作成の多くの側面から当て推量を排除します。この設計により、システムの複雑さがプロジェクトを「死の行進」で終わらせない、固定されたフラットなコスト曲線が可能になります。
Event Modelingは簡単です。BPMNとUMLのどちらを見ている場合でも、従来の設計手法は非常に重いものです。主な利点は、現在または将来のソリューションがどのように機能するか、または機能するかについての青写真を作成するために、はるかに少ない時間の投資で同じ価値を得ることができることです。目標は、書類の山を一掃し、組織を迅速に進めることです。Event Modelingの説明には15分しかかかりません。
他の主な利点は、実装を開始するための信頼できる計画があることです。今日のソフトウェアのほとんどの新しいプロジェクトは、盲目的な開発の開始に向かっています。Event Modelingが提供する重要なテストは、「情報が完全」であるかどうかを示すことです。これは、モデル内のすべてのサンプルデータを接続して、モデルがどこから来てどこに行くのかを特定できることを意味します。それができない場合は、設計が不完全であることがわかっているため、見積もりの推測が小さすぎる可能性があります。
InfoQ: Event Modelingの主な構成要素は何ですか ?
Dymitruk氏:
中心となるのは、イベント (黄色またはオレンジ色のボックス) と画面 (モックアップまたは白黒のワイヤーフレーム) が主要な構成要素です。実際、信頼性が高く、高速なものが必要な場合に、Rapid Event Modelingを実行するために必要なのはこれだけです。より完全には、コマンド (青いボックス) とビュー (緑のボックス) は完全なEvent Modelingの一部であり、ワークフローの入力ポイントと出力ポイントを示すために使用されます。これらはタイムライン上に、サンプルデータとともにスイムレーンに配置され、ワークフロー内のさまざまなアクタ、サブシステム、およびその他の概念を示します。すべての情報参照は転送のみであるため、gitログ履歴 (「有向非巡回グラフ」) と類似しています。
これらのビルディングブロックは、必要に応じて4つのパターンに配置されます。
- たとえば、ユーザの指示によるシステムの「入力」または変更。
- たとえば、システムによる「出力」または情報提供であり、ユーザのWebページによって要求されます。
- たとえば、支払いゲートウェイなどの外部システムとの対話を自動的に開始するための「自動化」。
- 自動的に統合するパートナ企業からの受注など、外部システムからデータを受信するための「トランスレーション」。
これらはすべて、UI->コマンド->イベント->表示間の相互作用に分解され、UIに戻ります。この歩調は、予測可能性を提供し、信頼できる見積もりでソフトウェアで得られるベストショットを提供するため重要です。これらの実装が多数あり、そこから非常に信頼できる速度が得られます。
InfoQ: Event Modelingを組み込むプロセスはどのように進めますか ?
Dymitruk氏:
組織に実装したい新しいサービスがある場合は、チームにEvent Modelingについて調べてもらい、1日かけてEvent Modelを作成します。これは、他のプラクティスと比較して非常に少ない投資です。チームメンバは、他の人にすばやく教え、会社全体でこれらのモデリングセッションを主導できます。厚い本を読む必要がないので、組織に組み込むのが最も簡単な分野の1つになります。
通常、新しいシステムのEvent Modelingセッションは、7つのステップに分割できます:
- 考えられるすべてのイベント (ビジネスで発生する可能性のあるもの) についてブレインストーミングします。
- それらのイベントをタイムラインに配置し、それが理にかなっているかどうかを判断します。あなたがすでにシステムを持っていて、1年間の運用中にキャプチャされた事実を見ていると想像してください。意味のないイベントを削除し、見逃した可能性のあるイベントを追加します。
- イベントの行の上に画面、モックアップ、またはワイヤーフレームを追加して、システムのユーザが途中で何を見ているかを示します。バックエンド処理が多い場合は、ダッシュボードとレポートを代役として使用して、管理者またはオペレーターに何が起こっているかを示します。次の2つの手順のために、間に十分なスペースを残してください。
- ユーザがシステムを変更する責任がある各場所にコマンドを追加して、画面をイベントに結合します。 自動的に行われる場合は、ロボットや歯車などのアイコンを使用して、コマンドを発行してもらいます。
- いくつかの情報がユーザに提示される各場所にビューを追加することにより、イベントと画面を結合します。これらのビューは通常、複数のイベントに接続されます。
- 画面をスイムレーンに配置して、どのユーザがどの画面を見ているかを示します。
- イベントをスイムレーンに配置して、ソリューションに含まれるサブシステムを示します。
ホテル予約システムのEvent Modelingプロセスのサンプルを以下に示します。
InfoQ: このプロセスは、既存のレガシーシステムまたは従来の状態ベースのシステムに採用できますか ?
Dymitruk氏:
はい ! これは、まだイベントソーシングを行っていない世界の他の地域にプロセスをもたらすための最新の取り組みです。テーブルの行がどのように変化するかを詳しく説明できます。それは、Fred Brooks氏 (人月の神話「Mythical Man Month」の著者) がずっと前に持っていた洞察です。テーブルはあなたが知る必要があるすべてを教えてくれます。したがって、それにEvent Modelを含めます。イベントは引き続き保持されますが、説明したとおりにシステムに保存されません。しかし、それらはユーザ中心の方法で起こったことの真実を捉えています。次に、Event Modelを、これらの結合がいつ役割を果たすかに関する重要なコンテキストを使用して、システム内の結合点を見つけるための参照として使用できます。
Event Modelingを使用して、レガシーシステムをブラックボックスのように扱い、サイドカーソリューションを構築することによってそれを進化させる方法を示すことができます。これは、レガシーソリューションのコードを開くのではなく、データベースを調べて補正アクションを追加することによって行われます。これには他にも詳細がありますが、継承したレガシーシステムの処理がはるかに簡単になります。レガシーコードベースに導入したコード行はどのような結果になるかわからないため、卵の上を歩く必要はもうありません。
InfoQ: Event Modelingの学習に役立つリソースは何ですか ?
Dymitruk氏:それらは、Event ModelingのWebサイトであるEventModeling.orgにリストされています。私が書いたイベントソースプロジェクトと従来のプロジェクトの2つの主要な記事があります。リソースページにSlackグループがあります。そのコミュニティの多くのメンバーがあなたを助ける準備ができています。週に2回開催されるEvent Driven Meetupもあります。