イベント駆動システムの採用が大流行りだ。システムの結合度を低下させる方策として，ほぼ"魔法"のように見られることもある，とBernd Rücker氏は，QCon London 2019で指摘している。そのプレゼンテーションで氏は，イベント駆動システムを取り巻く3つの一般的仮説 — イベントは結合度を低減する，オーケストレーションは回避する必要がある，ワークフローエンジンは難しい — を批判的に取り上げた。
イベントは結合度を低減する
Camunda Workflow Engineを開発したCamundaの創設者のひとりであるRücker氏は，イベントが結合度を低減することは認めており，通知サービスをその好例としてあげている。このサービスは，注文品の出荷を顧客に通知するような，すべての通知に対して明確な責任を持つ。イベントをリスニングすると同時に，他のサービスからは独立している。これによって，他のすべてのサービスには通知処理が不要になる。
しかしながら，ピアツーピアチェーン内の複雑なイベントフローでは，システム内のイベントの流れを把握することが難しくなる。発注に伴うイベント — 発注の実施，支払い受領，商品取り出し，商品出荷 — や，関連するサービスによって発行されるイベントからでは，ビジネスという観点から全体の流れを概要的に把握することは困難だ。さらにRücker氏は，イベント通知パターンは便利ではあるが，フロー全体の観点を失うリスクも生じさせるという点を指摘した，Martin Fowler氏の記事にも言及している。
イベントフローという観点を取り戻すアプローチのひとつは，監視とトレースを使用することだ。InfoQの記事でRücker氏は，その実施方法を具体的に説明している。
- 分散トレース
- データレイクまたはイベントモニタリング
- プロセスマイニング
- プロセストレース
ピアツーピアイベントチェーンに伴う潜在的な問題のひとつは，ワークフローを変更する必要のある — 例えば，納期を最適化するためのいお支払前に商品を用意する — 場合，いくつかのサービスがイベントサブスクリプションを変更する必要があることだ。さらにはチーム間やサービスのデプロイメントの調整，あるいは処理中の注文とシステム内のアクティブなイベントに関する考慮も必要になる。マイクロサービスチーム間の調整は，回避したいものひとつである。ここでRücker氏は，三本足のレース — 速度の低下とシステムダウンリスクの増大とを対比させたEric Evans氏のことばを紹介している。
オーケストレーションは避ける必要がある
ビジネスプロセス — Rücker氏の例で言えば顧客の注文 — が確実に実施されるためには，このエンドツーエンドの責務をひとつのサービスが担うべきだ，というのが氏の意見である。そうすることにより，企業にとって非常に重要な事について，ひとつのサービスが責任を負うことになる。これは理に適っている，というのが氏の意見だ。物事の順序をコントロールできる場所はただひとつ — ワークフローはサービスバウンダリの中にある。これによって，例えば"retrieve payment"のように，ワークフローをコントロールするためのコマンドを使うこともできるようになる。コマンドは，複雑なピアツーピアのイベントチェーンの存在を回避する上でも有効である。これがRESTへの移行ではなく，あくまでもメッセージングである点を氏は強調する。
何かに対して何かをするように指示する，という意味において，コマンドはオーケストレーションである。しかしRücker氏は，このオーケストレーションはマイクロサービスの内部であって，ESBのような外部のミドルウェアではない点を強調する。オーケストレーションのリスクは，それが結果として，やる気のないCRUDサービスを指示する少数のサービス，という形式に終わることだ。これに関連するものとして氏は，Sam Newman氏とその著書"Building Microservices"を紹介している。Rücker氏はこれをリスクとして認めながらも，オーケストレーションによって自動的に生じるものではない，APIの設計が不適切な場合にのみ起きるものだ，とした上で，支払いサービスを例に説明する。支払いサービスは，支払いに関するすべてを責務とし，外部サービスとの一時的な通信問題のような内部問題でなく，支払いが受け入れられたか，あるいは失敗したかのみを返す。
ワークフローエンジンは難しい
"ワークフローエンジンは難しい"という表現は，Rücker氏にとってもはや真実ではない。プロプライエタリで集中型のソリューションはすでに，あるいは以前から存在していたが，現代的なアーキテクチャに関連する新たなツールが現れている。それらのツールは軽量である。Rücker氏にとって軽量とは，数行のコードを書けば始めることができて，ワークフローをJavaなどのコードで定義することが可能である，という意味だ。AWS Step Functions, Azure Durable Functions, Google Cloud Composerのように，大手クラウドベンダはいずれも独自の製品を持っている。Activiti, Camunda, jBPM, Zeebeなど，軽量なオープンソースワークフローエンジンも存在する。
Rücker氏は，独立したコンポーネント(マイクロサービス)とKafkaをベースとした注文処理システムで自身のアイデアをデモするサンプルアプリケーションを公開している。カンファレンスの主要なプレゼンテーションは録画されており、今後数ヶ月の間にInfoQで公開される予定である。次回のQConカンファレンスであるQCon.aiは、AIとマシンラーニングに重点を置くもので、2019年4月15～17日にサンフランシスコで開催される。QCon London 2020は、2020年3月2～6日に開催が予定されている。