今天在推特上，吉米·博加德（Jimmy Bogard）就事件溯源的權衡取捨發表他的觀點：https://www.jdon.com/53732

如果事件溯源架構無法擴充套件，更快或更簡單，為什麼要使用它？

Event Sourcing為您提供了由您的軟體建模的完整、一致的世界範圍模型。那很吸引人。

我們想用軟體為現實世界建模

您可以將當今世界視為之前發生的所有事情的總和。環顧我的房間，我可以說我的書架是各種購買的總和，有些是四處走動，是關於閱讀和儲存物品的一系列決定。

我可以將自己視為發生的一切的總和，再加上我自己告訴自己的故事。我的下一個動作就是這樣的結果，加上我目前的環境，以及即將發生的事件。該行動本身是世界上的事件。

在生命中，在生物學中，我們看不到所有這些輸入事件，我們無法再次改變響應事件的演算法，不斷地再試。但是在軟體領域，我們可以！

當然，我們需要完美的建模和決策的可追溯性！這樣，我們就可以始終回答“為什麼”，並且在學習過程中可以改善理解和決策策略。

這就是事件溯源提供的。

我們希望我們的模型是完整且一致的。

遺憾的是，因為完整性和一致性存在衝突，無法為整個世界建模。但是，如果我們將“完整”限制在業務領域和公司範圍內，從理論上講這是可能的。

事件溯源提供了一種方法。

在事件源中，每一項輸入都是一個事件：有人要求安排諮詢活動。提供者註冊可用時間，活動；預約時間，活動。通知客戶事件；客戶出現事件；會話報告已提交事件。

我們可以總結過去的事件以獲得當前狀態。

瀏覽所有事件的時間表，將它們加起來。據此，我們可以計算世界狀況。

通過預定約會事件，我們可以構建當天日曆。

在月底，我們將構建有關服務客戶和提供商使用率的報告。基於此，我們可能會尋求更多的提供商，或者與活動較少的提供商進行交談。與其他部門相比，總部對我們辦公室的績效進行排名。（banq注：為大資料分析提供基礎架構）

我們需要更正

為了準確地模擬現實世界，我們需要考慮現實世界中發生的所有事情。

預約被取消。客戶不露面。會話報告提交較晚。（“上週的會議報告在哪兒？”“哦，對了，為時已晚，因為通往停車場的大門失靈了。不要為此收費。”）

資料延遲或丟失。如果您堅持認為不會發生這種情況（“每個提供商都必須在一天結束前輸入會話報告”），那麼您的模型就無法實現。

適應更正、合併遲到的事件，接受部分資料。您在模型中允許的現實越多，它就越準確。

我們可以根據當時可用的資訊評估過去的決定

當資料遲到時，報告在列印後會更改。事件源系統可以處理此類問題。

隨著過去幾天的新資料的到來，它將與那些日子的資料相加。報告變得更加準確。

我的一個朋友在諮詢中心工作，他接到總部的電話，例如“為什麼您的十二月使用率如此之低？”，他的回答是：“什麼？很好啊。”然後他再次執行報表，果然，情況有所不同。在他執行報告後，獲得了有關12月的更多資料，但現在總數有所不同。他無法複製他所看到的報告，這使得很難向總部解釋他的行為。

如果他們的軟體使用事件源，他可以說：“請從1月2日開始執行報告，您會明白為什麼我沒有采取任何措施。”

每個事件都記錄一個接收到的時間戳（表示我們瞭解該時間戳的時間）和一個有效時間戳（表示發生在現實世界中的時間戳）。然後，該軟體只能彙總1月2日之前收到的事件，以重現當天看到的報告。（大資料）

我們可以用新的邏輯重新評估世界

基於事件的系統不僅可以複製與前一天相同的報告，還可以問：如果更改報告邏輯該怎麼辦？那會是什麼樣子？

也許我們想將未報告的約會報告為“可能已取消”以反映不確定性。我們可以針對相同事件執行新邏輯，並將其與舊結果進行比較。

這意味著我們可以針對事件流執行測試並檢測行為更改。

我們需要記錄外部可見的決策以保持一致性

當我們更換軟體時，會危及一致性。

如果我們在2月更新報告邏輯，則總部在“截至1月2日”執行報告時，他們會看到與我朋友在同一天執行報告時看到的不同的東西。為了保持一致性，資料和程式碼都必須與1月2日的資料匹配。

或者，我們可以將報告本身建模為事件。“在1月2日，我說的大約是12月。”然後我們可以將其合併到報告邏輯中。

我們的系統所做的任何對外界可見的事情本身都是事件，因為它改變了外部人員和軟體的行為方式。為了一致地重現我們的行為，我們的系統可以記錄自己的行為，也可以保留所有資料和選擇它的程式碼。

到目前為止，這是很好的和確定性的。但是現實世界不是。

如果行為是確定性的，則可以在基於事件的系統中重現行為。在人類行為方面，我們無法獲得如此奢侈。我們的選擇來自多種影響，其中一些是相互矛盾的。一條推文啟發了我寫這篇文章。數以千計的其他推文使我分心。

衝突的資訊來自現實生活。

根據發生的事件，當我們正在建模的真實世界不一致時，事件源變得棘手。

現在說我們是一家貨運公司。當貨物在全球範圍內移動時，我們對貨物在集裝箱中的移動進行建模。當集裝箱被裝載到船上時，這是一個事件，當集裝箱被解除安裝時，這是一個事件。計劃船舶行程以及到達每個港口的事件。

一個事件說集裝箱1418被裝載到奧克蘭的Enceladus船上；另一件事是集裝箱1418計劃下一站在北京；另一事件是集裝箱1418在舊金山被卸下。另一人說，集裝箱1418在北京被清空了。你相信哪一個？

這個例子來自一個真實的故事，奇怪的事情發生了，您的系統是否允許人們報告現實情況？是否有“要求一個人去尋找那個集裝箱？真的是1418嗎？”

模稜兩可的決定是事件

無論系統做出什麼決定，都需要將其記錄為事件。

我們可以看到每個報告和決定的來源

如果有一些報告不均衡，並且作為錯誤反饋到了開發團隊，那麼事件源將為我們提供很好的跟蹤工具。

每個“我做出決定”或“我產生此報告”事件都可以記錄輸入的事件集以及為產生輸出而執行的程式碼版本。您可以擁有完整的出處。

這種軟體是 負責任的。它可以講述其決策，執行的操作以及原因的故事。當時的世界是什麼樣的。

這是一個美麗的酒店。有了充分的出處，我們可以瞭解發生了什麼。我們可以互相講故事。具有可重播性，我們可以更改程式碼，並檢視我們是否下次可以對其進行改進。

記錄一切變得荒謬

但是，關於事件的資料很快就變得龐大起來。每個報告消耗了數千個事件。現在，基於事件的當前狀態總和的每個決策都依賴於所有這些過去的事件，定義當前狀態的程式碼，從中獲取輸入的所有其他狀態以及它們的程式碼和事件集。

同時，其中一些事件已過時，不再符合最新程式碼所期望的格式。同時，我們仍然忽略了系統外發生的所有事情，因此我們完全不瞭解許多因果關係。“有人單擊了此按鈕。”為什麼？他們在螢幕上看到了什麼資訊？

在現實生活中，大多數資訊都會丟失。歷史將永遠不會被完全記錄。

完整性僅限於非常小的系統。請小心在此投入的精力。有意識地選擇邊界，在邊界之外您不知道發生了什麼。您不知道船廠，人的腦袋或另一家公司執行的軟體中真正發生了什麼。我們看到的世界範圍很小。

我們沒有為整個世界建模的原因是有原因的。

事件溯源將盡最大努力為整個世界建模。我們嘗試記住發生的所有重要事件，將其總結到軟體中的當前狀態中，制定決策並採取行動。

但是事件是亂序的。事件丟失了。事件相互矛盾。事件具有部分資料或舊資料格式。邏輯改變。我們不記錄一切事件。

有時值得考慮一下您應在事件源系統中做什麼，然後實施足夠的事件。保留產生的報告的副本，以便人們可以檢索它們而無需重新生成它們。在比日誌壽命更長的地方記錄困難的決定。

事件溯源功能強大。但這並不容易。希望對不想處理的極端情況進行認真思考。期望處理儲存以及速度和最新的權衡。允許人類進行更正，因為現實世界總是會讓您感到驚訝。