事件溯源定義

Question

“事件源”是一個應用程序的花哨名稱，它實現了“命令處理程序模式”，保存了成功執行的每個命令（ SeatReserved 、 OrderCanceled 、 BlaBlaBlaDone ），只執行插入（沒有更新和刪除，例如： Balance +100 , Account Closed ) 數據庫和所有選擇類似於select top 1 MailAddress from UserAddressTable where UserID=@value order by lastUpdated desc或select sum(balance) from UserTransactions where UserId=@value ???

Answer 1

您對Command端的建議定義基本上是正確的。

但是，沒有人說您必須將事件存儲在關系數據庫中。 事實上，這通常是一個糟糕的選擇。 在使用一個簡單的銀行帳戶示例時，您可能事先知道您將需要一個balance ，這意味着您可以在數據庫表中維護最新的余額。

但是，在從普通銀行帳戶示例中刪除的系統中，您可能無法提前准確了解所有事件將如何解釋。

這就是事件溯源很有價值的原因。 您永遠不會丟棄數據，因此，如果將來您意識到要執行一種您從未預料到的分析，您可以這樣做，因為您從未刪除任何數據。

當您解釋事件流時，您通常會執行這些事件的 折疊，從而產生聚合結果。 有時，出於效率原因，您提前進行，然后通常稱為快照。

與事件溯源密切相關的是CQRS的概念。

Answer 2

事件溯源是一回事，CQRS 是另一回事。

事件溯源，基本上是堅持您的模型（Akka 演員）在您的系統中所做的所有操作，以便擁有一個無狀態模型，該模型可以通過對所有這些事件進行再水化來及時給出狀態。

(baskedtCreated, productAdded, productAdded, productRemoved,productAdded, baskedPayed)

所以下次如果我想知道我之前的籃子的狀態是什么，系統會得到一個籃子的新實例，並用所有以前的事件補水，一個籃子的最終狀態被支付。

CQRS是命令查詢職責分離，它基本上是一種架構模式，用於將您的 RestAPI 分離為用於寫入的命令和用於讀取的查詢，讓您有機會完全獨立地擴展您的服務器。

Let´s say 4 machines for Queries(Read always is more expensive), 1 for Commands?

人們感到困惑的是，事實上 CQRS 是一種非常適合事件源的模式，因為Command(CreateBasket)在Command(CreateBasket) action-event(BasketCreated)效果非常好。

如果有人想在 Scala 中引入事件采購世界，這里我有一個非常好的開源項目https://github.com/politrons/Scalaydrated

Answer 3

事件溯源是關於使用過去的事件重建系統的狀態。

你不持久化命令（當然不禁止這樣做，但它與 ES 無關）。 你堅持事件。 在您的示例中，SeatReserved、OrderCanceled、BlaBlaBlaDone 是事件。 您可以通過讀取和應用這些事件而不是僅從數據庫讀取當前狀態來重建“預訂系統”的狀態。

我認為這是最基本的定義。 事件溯源經常與 CQRS 等其他東西一起被提及，因為將它們結合起來通常很有意義。

如果您想了解事件溯源和 CQRS，我推薦 Greg Young 撰寫的這篇文檔，他經常被提及是事件溯源一詞的創造者。

另外：我建議不要閱讀有關該主題的 Matin Fowlers 文章。 我不敢說他錯了……但這篇文章至少可能令人困惑（尤其是有關外部更新和其他內容的內容）。 請注意他在開頭的免責聲明：“我沒有時間進一步研究它們”。