活動海報

這是我遇過幾次的應用程式風格。應用程式主要是提供報表，讓使用者即時了解某件事的狀態。這是一個主動式應用程式，使用者可以大量控制他們正在查看的內容，他們可以在特定區域深入探討，並普遍操控他們的顯示；然而，它仍然至少主要是一個唯讀應用程式。

這種應用程式的另一個特點是，它是一個事件來源應用程式，也就是說，對顯示狀態的所有更新都是透過事件物件進行的，這些物件可以儲存和排隊。這些事件可以是為應用程式量身打造的，也可以是外部訊息串流。Chris Stevenson 告訴我一個範例事件海報：Inkblot，它使用資料庫表格，寫入另一個應用程式，其中列會插入為事件。

將這兩個特點結合在一起，你會發現不需要資料庫來儲存顯示的記憶體中狀態。通常會有一些初始狀態載入系統，例如一天開始時的世界，之後所有變更都會透過事件串流載入到事件海報的記憶體中狀態。如果應用程式失敗，它只會重新載入初始狀態並重新播放佇列中的所有事件。

不儲存應用程式狀態會帶來兩個主要優點：首先，應用程式非常快速，因為在人員操控系統時不會涉及磁碟存取。Marcel Weiher 告訴我 BBC 的新聞饋送應用程式，其中一個舊版本在製作中需要幾秒鐘才能處理一個請求，而替代的事件海報應用程式在他的筆電上可以輕鬆處理每秒數百個請求。

其次，所有記憶體與資料庫之間的複雜對應關係都已移除，這讓人們得以建構一個針對顯示需求而設計的良好網域模型，而且不必擔心持久性問題。（如果顯示行為碰巧符合關聯行為，這可能不會帶來太大的優勢，因為這時 SQL 就會佔上風。）

顯然，這種應用程式有其限制。資料量會受到記憶體容量的限制，儘管現今主記憶體的容量已經相當龐大，但就在不久之前，吉位元組的資料庫還被視為相當龐大。您也會遇到事件溯源的其他限制。

要將這種系統進行叢集非常容易。您所要做的就是確保事件會廣播到所有副本。如果其中一個副本發生故障，由於狀態幾乎總是同步的，因此很容易用另一個副本取代它。

我說這些應用程式是唯讀的，但這並不完全正確。要進行更新，海報只要擷取資訊並將其傳送給作為事件來源的後端應用程式即可。它不會直接更新自己的資料，而是會等待適當的事件從來源應用程式的串流中傳送過來。這可確保多個海報會顯示相同的資料，而且來源應用程式可以對變更執行任何必要的處理。

我們為這種應用程式想一個好名字而傷透腦筋。有幾個重要的特徵，如果名稱能喚起這些特徵會很好：事件串流、暫存資料、僅供顯示。我認為「海報」這個名字很好，因為它讓我想起每天都會被撕下並更換的、張貼新聞的海報留言板。

事件海報是使用 CQRS 搭配事件協作的系統的自然選擇