イベントポスター

これは私が何度か出会ったアプリケーションのスタイルです。このアプリケーションは、主にユーザーに何かの状態に関するリアルタイム情報を提供するレポートアプリケーションです。ユーザーは、見ているものの種類を詳細に制御し、特定の領域をドリルダウンしたり、表示を操作したりできるため、アクティブなアプリケーションです。しかし、少なくとも主に読み取り専用のアプリケーションです。

この種のアプリケーションのもう1つの特徴は、イベントソーシングアプリケーションであることです。つまり、表示状態へのすべての更新は、保存およびキューイングできるイベントオブジェクトを介して行われます。これらのイベントは、アプリケーション用にカスタムメイドすることも、外部メッセージストリームにすることもできます。Chris Stevensonは、データベーステーブルを使用したイベントポスターの例として、Inkblotについて教えてくれました。これは別のアプリケーション用に作成されたもので、行はイベントとして挿入されました。

これら2つの特性を組み合わせると、表示のメモリ内状態を保存するためのデータベースが不要であることがわかります。システムにロードする初期状態（たとえば、1日の開始時の世界）はしばしばありますが、その後、すべての変更はイベントストリームを介してイベントポスターのメモリ内状態に行われます。アプリケーションに障害が発生した場合、初期状態をリロードし、キュー内のすべてのイベントを再生するだけです。

アプリケーションの状態を永続化せずに実行すると、2つの大きな利点があります。まず、システムを操作する際にディスクアクセスがないため、アプリケーションは非常に高速です。Marcel Weiherは、BBCのニュースフィードアプリケーションについて教えてくれました。以前のバージョンでは、本番環境でリクエストを処理するのに数秒かかりましたが、交換用のイベントポスターアプリケーションは、彼のラップトップで1秒間に数百件を簡単に処理しました。

第二に、メモリ内とデータベース間のマッピングの複雑さがすべて解消されるため、表示ニーズに合わせた優れたドメインモデルを構築し、永続化について心配する必要がなくなります。（表示動作がリレーショナル動作と一致する場合、SQLが有利になるため、これはそれほど大きな利点ではないかもしれません。）

明らかに、この種のアプリケーションには限界があります。データはメモリに収まるものに限られますが、最近ではメインメモリは非常に多くのデータを保持できます。ギガバイトデータベースがかなり大きいと考えられていたのはそれほど昔のことではありません。また、イベントソーシングの他の制限にも遭遇します。

この種のシステムをクラスタ化するのは非常に簡単です。イベントがすべてのコピーにブロードキャストされるようにするだけです。1つがダウンした場合、状態は常にほぼ同期しているため、別のものに簡単に置き換えることができます。

これらのアプリケーションは読み取り専用だと言いましたが、それは厳密には真実ではありません。更新を行うために、ポスターは情報をキャプチャし、イベントのソースであるバックエンドアプリケーションに送信するだけです。独自のデータを直接更新するのではなく、ソースアプリケーションからストリームを介して適切なイベントが来るのを待ちます。これにより、複数のポスターに同じデータが表示され、ソースアプリケーションは変更に対して必要な処理を実行できます。

私たちは、この種のアプリケーションの良い名前を付けるのに苦労しました。イベントストリーム、一時データ、表示専用など、名前が連想させることができれば重要な特性がいくつかあります。「ポスター」は、毎朝破棄されて交換されるポスターにその日のニュースを掲載するメッセージボードを連想させたので、良いと思いました。

イベントポスターは、イベントコラボレーションでCQRSを使用するシステムに適しています。