イベント、プロセス、サービス：ビジネスプロセスを自動化するための最新のアプローチ

まとめ

• イベント駆動型アーキテクチャを使用して接続を減らすことは、マイクロサービスを設計する際の非常に一般的なアイデアです。
• イベント駆動型のビジネスロジックは、分散データおよび横断的な機能に適しています。 ただし、イベントをサービス間で転送するための複雑なチェーンを構築しないでください。 イベントではなくコマンドを使用してサービスを調整すると、さらに多くのサービスを利用できます。
• ESB（記事のコンテキストでは「Enterprise Service Bus」-「スマートバス」-約Transl）。マイクロサービスアーキテクチャとの組み合わせは不十分です。 シンプルなデータ伝送チャネルとスマートクライアント（スマートエンドポイント、ダムパイプ）を使用することをお勧めします。 ただし、1つの神のようなサービスを得るのを恐れて、他のサービスのサービスコーディネーターを拒否しないでください。ビジネスロジックにはまだ家が必要です。
• 過去のワークフローエンジンはほとんどベンダーに依存していました。 いわゆる「ゼロコード」ソリューション-実際には、開発者にとって悪夢に変わりました。 現在、軽量でシンプルなワークフローコントロールがあり、その多くはオープンソースです。
• 独自のステートマシンを記述する時間を無駄にしないでください。 代わりに、市販のソリューションを使用して複雑さを避けてください。

イベント駆動型アーキテクチャを使用して、疎結合を実現します。

このようなアドバイスは、マイクロサービスのトピックに関する議論でよく見られます。 特に、 DDD（Domain-Driven Design）コミュニティで人気があり、サポートされています。 それにもかかわらず、イベントモデルの潜在的な支持者である記事の著者は、質問をしました。 答えとして、3つの一般的な仮説が考慮されました。

• イベントにより接続性が低下する
• 神を中心とした（中央管理）サービスは避けるべきです
• ワークフローエンジンには独自の痛みがある

以下の例は人為的ですが、Zalandoでの注文処理の実際のビジネスプロセスに触発されています。 4つの分離されたアプリケーションに4つの境界付きコンテキストがあるとします（これらは、 マイクロサービスと他のアーキテクチャの代表の両方である可能性があります）。

イベントの関連性を減らす方法

商品が在庫にあり、すぐに出荷できるかどうかをCheckoutサービスがユーザーに通知する必要があるとします。 もちろん、Checkoutは在庫サービスに在庫商品の数量を直接照会できますが、これによりCheckoutは在庫に依存します。 接続性を強化します。

代替アプローチ：在庫は在庫変更イベントを発行します。 Checkoutはイベントをリッスンし、最新の値をローカルキャッシュに保存します。 このデータはコピーであり、その完全な整合性はまったく必要ありません。 ただし、分散システムでは通常、一定レベルのイベント整合性が必要です。

別のシナリオ：エンドツーエンド機能。 注文の特定のステップで顧客に通知を送信する必要があるとします。 顧客の設定と連絡先の詳細を保存する完全に自律的な通知サービスをシステムに追加できます。 「支払いの受け取り」や「注文の発送」などのイベントを受信すると、このサービスは他のサービスへの変更を必要とせずに手紙を送信します。 ご覧のとおり、 イベント駆動型アーキテクチャは非常に柔軟であり、新しいサービスの追加や古いサービスの拡張を簡単に行うことができます。

複雑なイベント送信チェーンの危険性

イベント駆動型アーキテクチャを実装する開発者はしばしば夢中になります。イベントはシステムの接続性を非常に低下させるので、どこでもいつでもイベントを使用しましょう。 問題が発生するのは、チームが1つのサービスから別のサービスへの一連のメッセージを通じてビジネスプロセス（注文処理など）を実装するときです。 最も単純な例を考えてみましょう。チェーン内の各サービスに、何をするか、どのイベントを送信するかを自分で決定させます。

はい、動作します。 しかし、問題は、チェーン内のリンクの1つがプロセス全体の明確なビジョンを持っていないことです。 これにより、ビジネスプロセスを理解するのが難しくなり、（さらに重要なことですが）変更するのが難しくなります。 現実の世界では、ビジネスプロセスは単純とはほど遠いものであり、通常はさらに多くのサービスが含まれることに留意してください。 この記事の著者は、誰も詳細に理解していない複雑なマイクロサービスシステムを見てきました。

次に、支払いを行う前に、倉庫で商品の予約を実装する方法について考えます。

注文を完了するための手順の順序を単純に変更するには、いくつかのサービスを修正して再展開する必要があります！ これはマイクロサービスアーキテクチャのアンチパターンです。その主な原則は、接続性の低下と分離性の向上に努めることです。 したがって、特に高い複雑さが予想される場合、同様のサービス間プロセスでイベントを使用する前によく考えてください。

チーム、ただし集中管理の必要なし

ビジネスプロセス全体を別のサービスに保持する方が賢明です。 このようなサービスマネージャーは、「支払いを行う」などのコマンドを残りに送信できます。 同時に、互いに関するマイクロサービスの知識は避けるべきです。 著者はこのパターンを「オーケストレーション」と呼んでいます。 例：「注文は、支払、在庫、および出荷サービスを管理（調整）します。」

オーケストレーションといえば、奇跡的なエンタープライズサービスバス（ESB）バスと、 ビジネスプロセスモデリング（BPM）ソリューションが思い浮かびます。 これらの洗練された独自のツールは評判が悪く、正当な理由があります。 多くの場合、簡単で理解しやすいテストと軽量なアプリケーション配信を奪われます。 同時に、ジェームズルイスとマーティンファウラーはマイクロサービスアーキテクチャの基礎の多くを築き、「スマートエンドポイントとシンプルな伝送チャネル」（ スマートエンドポイント、ダムパイプ ）の使用を提案しました。

上記の図は、スマートバスの使用を意味するものではありません。 注文処理のすべての制御は、個別の注文サービスマネージャーに委任されます。 チームは、好みのテクノロジーを使用して、このサービスを便利に自由に実装できます。 したがって、ビジネスプロセスの変更は1つのマイクロサービスのみに影響します。 さらに、ビジネスプロセスを1か所に集中すると、理解しやすくなります。

サムニューマンの著書 『 Building Microservices 』では、時間が経つにつれて、そのようなサービスマネージャーが神のようなモンスターに成長するリスクを考慮しています。 このような神のサービスはすべてのビジネスロジックを収集し、残りは貧弱なサービスに退化するか、さらに悪いことに、それらは単純なCRUDになります。

これは、イベントアーキテクチャを損なうコマンドの使用が原因で発生しましたか？ または、オーケストレーション自体の問題ですか？ どちらもありません。 ファウラーの「スマートエンドポイント」を見てみましょう。 スマートエンドポイントの定義は何ですか？ 優れたAPIデザイン。 支払いサービスの場合、「返品の支払い」などのコマンドに応答し、「支払い完了」、「支払いの失敗」などのイベントを公開する高レベルAPIを開発できます。 すべての機密情報（たとえば、ユーザーのクレジットカードに関する情報）は、マイクロサービス内にのみ保持する必要があります。 この場合、Paymentマイクロサービスは、サービスマネージャーまたは他の誰かが使用しても、貧弱になりません。

長期にわたるサービス

スマートエンドポイントと適切なクライアントAPIを開発するには、一部のプロセスに時間がかかる可能性があると想定する必要があります。また、背後で実際のビジネス上の問題を解決する必要があります。 クレジットカードの有効期限が切れた場合、顧客は状況を修正する機会を得る必要があると仮定します（例はGitHubに触発され、ビジネスアカウントは不払いの2週間後にのみ閉鎖されます）。 支払いサービスが顧客のアクションを待つことに対応していない場合、彼はこのタスクを顧客、つまり注文サービスに委任できます。

ただし、この機能をペイメントサービス内に保持すると、アーキテクチャがよりクリーンになり、DDDの「境界コンテキスト」の考え方との一貫性が高まります。 顧客が新しいクレジットカードを開始するまで待機するという事実は、支払いが引き続き行われることを意味します。 その結果、Payment APIはクリーンでシンプルになります。 待機が2週間になることもあります。これを「長期にわたる」ビジネスプロセスと呼びます。

サービスステータスストレージ

長期実行プロセスは、「支払いを待っています」などの状態をどこかに保持する必要があります。 再起動後にアプリケーションの状態を維持することは、新しいタスクとはほど遠いもので、次の2つの一般的なソリューションがあります。

• Entity、Persistent Actorなどに基づいて独自の状態保存メカニズムを作成します。 誰がStatus列を持つOrderテーブルを作成したことがありますか？ それだけです！
• ステートマシンまたはワークフローエンジン全体を理解し、受け入れます。 そのようなツールの多くは、非常に成熟したものを含めて利用可能です。 しかし、進歩はまだ止まっていない。たとえば、 NetflixとUberはオープンソースソリューションを開発している。

この記事の著者の経験によると、状態を保存するための自転車は、しばしば自作の有限状態マシンに進化します。 書かれたシステムが新しいタスクをもたらすからです。 例：

• タイムアウトのサポート（「スケジューラーを追加しましょう」）、
• レポートツール（「ビジネスマンがSQLを使用して適切なデータを取得しないのはなぜですか」）
• 監視ツール。

有限状態マシンを作成するのは、 "Not-Invented-Here"シンドロームだけでなく、ビジネスプロセスを自動化する昔ながらの手段に値するという否定的な評判のおかげです。 多くの人は、同様の「ゼロコード」ツールで苦しい経験をしています。 経営者は、開発者を排除することを望んでテクノロジーを購入します...もちろん、それは起こりません。 代わりに、重量級の独自技術のサポートはIT部門の肩にかかっており、永遠に異質で拒否された要素のままです。

軽量のステートマシンとワークフローエンジン

数行のコードを記述するだけで十分な、シンプルで柔軟な作業用のツールがあります。 これらは「ゼロコード」ソリューションではなく、通常の開発者ライブラリです。 彼らは有限状態マシンで仕事を引き受け、すぐに成果を上げ、利益をもたらし始めます。

通常、このようなツールを使用すると、BPMN ISO表記を使用するか、JSON、YAML、またはJava、Golangなどに基づくDSLを使用して、ワークフローをグラフィカルに記述することができます。 重要なポイント：ワークフローの説明-これは、プロセスで実行される実際のコードです。

BPMNなどは、時間管理、タイムアウト、ビジネストランザクションといったかなり複雑な操作をサポートしています。 しかし、これはかなり一般的で成熟した表記法であるため、複雑な問題を解決するための適合性について話すことができます。

上の図では、ワークフローインスタンスは「Goods Fetched」イベントの受信を待機していますが、待機時間は制限されています。 タイムアウトが発生した場合、特別な補正アクションを実行してビジネストランザクションをロールバックします。 この場合、支払いは送信者に返されます-ステートマシンは以前に実行されたすべてのアクションを記憶するため、対応するすべての補償コードを実行できます。 ステートマシンがビジネストランザクションを管理できるのは、ここでの考え方は佐賀パターンと同じです。

グラフィック表記も一種の「ライブ文書」であり、陳腐化して実際のシステムから脱却する機会はありません。 テストはどうですか？ 一部のライブラリは、以下を含む単体テストをサポートしています 長期実行シナリオ向け。 たとえば、 Camundaは、テスト実行ごとにテスト実行スクリプトを含むHTMLを生成します。これは、通常のCIレポートに簡単に挿入できます。 この場合、グラフィカルな表記はさらに大きな意味を持ちます：

ワークフローライブインサイドサービス

特定のワークフローフレームワークの選択と使用は、各開発チームの裁量で個別に分散する必要があります。 ステートマシンは実装の詳細であり、サービスの外部からは見えません。 企業にとって唯一のグローバルフレームワークは必要ありません。 ステートマシンは、開発を簡素化する単なるライブラリです。

さらに、ステートマシンはビジネスロジックの一部です。 ツールに応じて、アプリケーションのプロセスに埋め込む（Java、Spring、Camundaなど）か、クライアントライブラリ（ Zeebe ）またはREST API（CamundaおよびNetflix Conductor）を介して通信する別のプロセスとして使用できます。 実行時間の長いビジネスタスクをサポートする既製のステートマシンを使用すると、真のスマートエンドポイントを実装することでビジネスロジックとAPI設計に集中できます。

コードを表示

ドライ理論に陥ることなく、この記事の著者はデモアプリケーションを作成し、 GitHubに投稿しました。 記事で提示されたアイデアの実例があります。

オープンソースライブラリ（Spring Boot、Camunda、Apache Kafka）のみを使用するJavaコード。

結論

• イベントは接続性を低下させますか？ 常にではありません。 イベントは、分散化とエンドツーエンド機能に最適ですが、サービスからサービスへメッセージを送信するための複雑なチェーンを作成しないでください。 代わりに、管理チームとサービスを使用してください。
• 中央集権化は避けるべきですか？ 狂信なし。 スマートESBは、マイクロサービスでは不十分です。 シンプルな伝送チャネルとスマートエンドポイントを優先します。 内部にビジネスロジックを備えたスマートサービス-すべてを吸収した神のようなサービスマネージャーの出現を防ぎます。 スマートサービスは、長期にわたるビジネスプロセスを実行できます。
• ワークフローエンジンは苦痛ですか？ 常にではありません。 過去にベンダーロックがあり、「ゼロコード」ツールを作成しようとしました。 現在、一般的な問題を解決する軽量のオープンソースフレームワークがあります。 有限状態マシンを循環させず、既製のツールを使用します。