經驗分享：從CRUD重構到事件源ES的有狀態系統 -Stitcher.io

CRUD系統
首先討論一種如何基於CRUD系列的設計方法：
在這樣的系統中，可能會有兩個域組：Product和Order，以及兩個使用這兩個域的應用程式：an AdminApplication和a CustomerApplication。

在先前的專案中成功使用了該架構之後，我們可以簡單地依靠它一段時間。但是，它有一些缺點，特別是對於這個新專案：我們必須牢記，報告和歷史記錄跟蹤是訂購過程的關鍵方面。我們希望在我們的程式碼中如此對待它們，而不僅僅是程式碼的次要功能或副作用。
例如：我們可以使用活動日誌包來跟蹤有關訂單發生的“歷史訊息”。我們還可以開始在訂單和歷史記錄表上編寫自定義查詢以生成報告。

事件溯源EventSourcing
自然地，我們著眼於事件源，這是一種可以滿足上述要求的出色而靈活的解決方案。但是，沒有什麼是免費的：事件源需要編寫很多額外的程式碼才能完成其他簡單的事情。在通常需要簡單的CRUD操作來處理資料庫中資料的地方，現在您不得不擔心排程事件，使用投影儀projectors和reactors處理事件，同時始終牢記版本控制。
儘管很明顯，事件源系統可以解決許多問題，但即使在不會增加任何價值的地方，它也會帶來很多開銷。
如果我們決定Orders使用事件源，而Orders依賴於Products模組中的資料，如果Products不實現事件源，則我們將無法重建Orders狀態，因此，我們可以透過事件來源獲取所有資訊，或者為該問題找到解決方案。

事件源所有的東西嗎？
透過在我們的一些業餘專案中使用事件源，我們痛苦地意識到，我們不應該低估它所增加的複雜性。此外，格雷格·揚（Greg Young）表示，整個系統的事件溯源通常不是一個好主意-他對事件採購的誤解有完整的論述，值得一看！
對我們來說很明顯，我們不想為整個應用程式提供事件源。這樣做根本沒有任何意義。唯一的選擇是找到一種將有狀態系統與事件源系統結合在一起的方法，但是令人驚訝的是，在這個主題上我們找不到很多資源。
儘管如此，我們還是進行了一些勞動密集型研究，並設法找到了我們問題的答案。答案不是來自事件溯源社群，而是來自完善的DDD慣例：有界的上下文。
如果我們想要的Products模組是一個獨立的，有狀態的系統，我們必須清楚地尊重Products和Orders之間的界限，而不是一個整體單體的應用程式，我們將不得不將這兩個模組視為兩個單獨的上下文，包括單獨的服務，僅允許以保證該Order上下文永遠不會以無效狀態結束的方式相互交談。
將其Products視為透過REST API訪問的單獨服務。即使API離線或對其資料結構進行了更改，我們也可保證事件源應用程式仍然可以正常工作。

更多詳細點選標題見原文。