作者 ｜ Savan Kharod
譯者 ｜ 平川
如果對各種架構風格都有個透徹的了解，設計者就能夠建構新型的、反應性的、有彈性的大型應用。是以，遵循這些經過行業檢驗的标準可以節省時間、保證可靠性，并推動目标實作。畢竟，企業有什麼理由要花時間和資源來重新發明輪子？
但僅僅了解不同的架構，如基于 CRUD 的架構、基于微服務的架構 和基于事件源的架構，并不足以做出全面的決策。我們需要深入了解細節，并了解它們各自的特性、适用性和所提供的價值。在這篇文章中，我們将看一下 CRUD 和事件源架構，思考為什麼應該考慮從前者遷移到後者。
什麼是 CRUD？
CRUD 是建立、讀取、更新和删除的縮寫。它構成了資料庫的四個指令，四個不言自明的指令，這些指令被認為是持久性存儲管理的必備要素。這種模式被各行各業的企業廣泛用于跟蹤客戶資料、員工資訊、支付記錄、賬戶等。
讓我們快速說明一下 CRUD 的正常事件流。Gary 正在浏覽一個電子商務網站。他把一個遊戲機、一個控制器和一個遊戲添加到購物車中。此時，購物車的資料庫看起來大概是這樣：
假如我們添加另外一個物品（如耳機），則資料庫會變成下面這樣：
如果 Gary 删除了耳機，則表就會變回之前的樣子。此外，如果他另外添加一個控制器，則資料庫會變成下面這樣：
本質上，資料庫遵循建立 - 讀取 - 更新 - 删除的方法來維護表。“更新”和 “删除”功能是 CRUD 的特點。
CRUD 方法的局限性
雖然 CRUD 方法由于其操作的輕量化和簡單性而備受青睐，但它也有自己的一系列局限，這包括：
對于 CRUD，最常見的批評是原始、過時。與其說它是一種架構或設計，不如說它是一個可供遵循的循環步驟，不管是建構一個資料庫還是一個 API。
CRUD 依賴于資料庫中狀态的持久性。然而，考慮到目前資料操作事件的動态性，這種資訊的存儲可能是浪費和資源密集型的。
盡管 CRUD 架構很簡單，但在開始階段，它需要人們花費大量的精力編寫大量的代碼。盡管如此，當涉及到雲負載均衡時，CRUD 卻無法勝任。
雖然 CRUD 代碼開始時可能很簡單，但當它開始與其他服務或微服務共享資料時，就會出現與狀态同步和故障處理有關的問題。
CRUD 架構所涉及的複雜性将需要同樣複雜的解決方案，這可能會延伸到故障跟蹤、手動狀态記錄、異步批處理等。這方面的考慮在編碼和整合上都會比較艱難。
在 CRUD 模型中，實體執行個體通常是雙重表示，一是記憶體中的可變對象，二是關系資料庫表中的一個可變行。這樣的結構導緻了臭名昭著的對象 - 關系阻抗不比對。試圖彌合這種鴻溝的努力卻進一步增加了這一架構的複雜性。
什麼是事件源架構？
事件源是一種資料存儲技術，被認為是 CRUD 的更新版。它隻關注建立和讀取功能，而完全省略了 CRUD 中更新和删除值的操作。更簡單地說，你不能通過事件源執行破壞性的操作。
那麼，它是如何克服 CRUD 面臨的挑戰的？
這裡有個有趣的地方：與 CRUD 遵循的傳統方法不同，事件源将變化逐個記錄下來，作為目前狀态随時間變化的一系列增量，而不是持久化目前狀态本身。通過這種方式，事件源賦予了狀态變化可追溯性。在大多數情況下，這種設計通常與領域驅動設計（DDD）和指令查詢責任分離（CQRS）設計模式相結合。
為了更好地了解事件源架構，讓我們以 Gary 的銀行賬戶為例。假設 Gary 的賬戶裡有 2400 美元。他用 499 美元購買了 PS5 遊戲機。電子商務網站為他提供了 49 美元的返現。在這種情況下，事件源表會是這樣的：
通過追蹤一段時間内的取款和存款，可以計算出他目前的賬戶餘額為 1950 美元。這種狀态的複原和事件的回放被稱為重放。
我們可以把事件源視為客戶活動的日志。
如果我們從電子商務平台的角度來看 Gary 的活動，添加遊戲機是第一個事件，添加控制器是第二個事件，以此類推。事實上，結賬過程也是一個獨立的事件。如果 Gary 不小心在購物車中添加了三個控制器（例如，事件 1、2 和 3），然後他又删除了一個，那麼删除也是一個獨立的事件：事件 4！
采用事件源架構的好處
從對事件源的基本了解來看，它似乎是一個更好更完善的替代方案，克服了 CRUD 的缺點。為了進一步說明這一點，讓我們看一下事件源已被證明了的優勢。
事件源遵循事件驅動的架構，友善在狀态變化時可靠地釋出事件。
它通過持久化事件而不是領域對象，克服了 CRUD 中出現的對象 - 關系阻抗不比對問題。
它維護了一系列事件的記錄，可以在隻限追加的狀态下進行操作。通過消除狀态跟蹤和實體關系的需求，編寫讀寫資料庫的事件源代碼更容易。
由于保留了實體如何到達目前事件的日志，是以事件源保證了審計資料和交易資料的一緻性，因為它們是一樣的。此外，它也是一個很好的故障保險，因為資料可以從事件日志中重建。
所有的事件隻是被追加到現有的資料庫中，并且更新和删除功能已被去掉，事件源架構隻關注寫入，這提高了其性能。
事件源允許對事件流進行分析，這有助于企業從中擷取關鍵資訊。他們可以獲得所有系統活動的頂層視圖，而不會使寫入功能複雜化。
遵循事件源模型的架構更容易測試和調試，因為在引入指令和事件之前，可以對其進行模拟測試。此外，事件日志還可以作為一個很好的調試活動記錄，如果發現問題，可以在受控環境中重放事件日志，以了解導緻異常的原因。
它可以存儲任何類型的資訊，任何消費者隻要獲得授權，就可以通路這些資訊。它允許通過時間查詢實體在任何時候的狀态。是以，它非常靈活。
與單體架構相比，事件源應用程式更容易遷移，因為它們遵循基于微服務的架構。之是以如此，是因為參與事件交換的業務實體之間是松耦合的。
結 語
随着越來越多的應用程式需要以有序和異步的方式傳遞實時資料，企業對事件源的需求也越來越大。此外，它也是在網絡規模上消費和管理應用程式日志資料的絕佳方法。在這種情況下，事件源成了一個唯一的事實來源，提高了應用程式的可靠性。
那麼，你所在的企業打算何時從 CRUD 遷移到事件源架構？
https://dzone.com/articles/why-do-you-need-to-move-from-crud-to-event-sourcin?accessToken=eyJhbGciOiJIUzI1NiIsImtpZCI6ImRlZmF1bHQiLCJ0eXAiOiJKV1QifQ.eyJhdWQiOiJhY2Nlc3NfcmVzb3VyY2UiLCJleHAiOjE2NDIxNDU1NzUsImciOiJLOEdoZGtjdlF2SHkzeDhwIiwiaWF0IjoxNjQyMTQ1Mjc1LCJ1c2VySWQiOjI0MzYwNzkwfQ.yHCE5wZnN1J6Gb4eKsvz-XrB82uZpWtFq3OmKmoHzbg