問：“如何使客戶方便使用事件溯源Eventsourcing？”

答：“只要不告訴他們，他們應該不在乎”

更多答案：

我有一個合理的經驗法則來決定您的業務領域是否適合事件溯源：是否涉及律師，會計師或審計師？

歷史記錄在物聯網，運輸，商業，ERP，CRM，旅行，任何形式的預訂等方面都非常有價值。

經過10年的電子商務，在金錢或其他一切有風險的事情上，我總是會選擇ES。

我認為將事件源與歷史記錄收集用於審計目的有點誤導。如果您沒有很好定義/穩定的事件格式，更改要求或有時需要及時返回（例如，不是“僅追加”），則從事件重播會更加困難。

歷史可以像版本化文件一樣儲存。但是捕獲系統行為是非常寶貴的。

我想知道我們是否在這裡缺少一些假設前提，可能的前提是，在使用ES並將系統投入生產之前，您已經對領域和穩定的業務模型具有公認的，非常好的理解？因為我的經驗是，這比聽起來要難。

我同意，由於正規化的不斷變化和基本模型的變化，對於不斷髮展的業務而言，未經驗證的領域模型對事件源來說是一團糟。但這並不經常發生。我今天在會議上提到了它。

我的經驗是，ES系統實際上比傳統系統更容易發展。在傳統系統中，我們通過假裝舊資料發生在新模型中進行遷移。這種遷移是痛苦的，昂貴的，有風險的，並且通常是不可逆的。我們剛好習慣了那種痛苦。或者我們只是不遷移，而只是新增更多的差勁CRU操作，直到它變成無法理解的遺留混亂，這也是我們習慣的痛苦。在ES中，更改是明確的：我們將舊資料保留在舊模型中。該事件在此時間點在此模型下執行，沒有任何影響。另一個好處：我們的事件歷史記錄可以跟蹤模型更改。GDPRWasActivated是一個域事件，UpgradedCustomerToNewMobilePlan也是如此。模型更改成為模型本身的第一流。同樣，有明確的基本複雜性。

banq注：當有多個來源更改一個狀態，比如設定為true或false，如果你將這個狀態欄位設計到資料庫表中，那必須所有來源都需要知道有這個表欄位，一旦表結構改變，影響全面。但是使用事件溯源，無論內部自己的操作，還是載入的第三方外掛，或者呼叫第三方API，所有修改聚合狀態的事件都會被放入事件日誌，那麼我們關心的狀態是true和false可以從這個事件日誌中追溯到，也許這是過了N多年以後的事情。