在實現具有事件源的應用程序時，工作中的持久性引擎是事件存儲。也就是說，按事件或事件的過去時，事件的追加記錄。通過簡單地通過應用程序重播事件，可以再現任何時間點的狀態。附加事件存儲是否會生成僅附加代碼庫？
我擔心的 - 沒有這個追加只事件存儲不可避免地導致追加只代碼庫？如果刪除甚至更改代碼可能會使應用程序無法重播事件序列，那麼如何維護代碼庫？代碼的源代碼行數是否會減少？
如果必須修改業務規則，或者更糟糕的是，如果應用程序初期早期的惡意程序錯誤允許它進入禁止狀態會怎麼樣？錯誤的代碼必須無限期地保持活着嗎？當然，理論上來說，很多這些問題都可以通過事件版本控制，事件模式，快照版本控制等來處理。但是，在這一點上，事件採購不會成爲負擔嗎？
事件採購是一項相當新的技術，至少在生產中。我懷疑已經運行了幾年的應用程序已經很少了。他們在10年後會是什麼樣子？對於企業應用程序來說這不是一個不現實的時代。
我的問題 - 這個只能附加事件存儲不可避免地導致只有附加代碼庫嗎？
不，它意味着一個附加的模式，它與您的實現分離。
如果業務規則必須修改，或者更糟糕的是，如果應用程序的早期早期的惡意錯誤允許它進入禁止狀態會怎麼樣？錯誤的代碼必須無限期地保持活着嗎？
不是真的 - 域與持久表示是分離的。
是的，您需要將一些常見方案合併到您的設計中;就像您可能需要補償事件歷史中的錯誤。
如果您只是存儲當前狀態，那麼它與您所做的基本上不同。如果您的數據庫中的聚合表示處於錯誤狀態，則只需更新它就行了吧？通過改變一些領域到他們應該是什麼。
這個想法在事件採購中是一樣的;你有一個事件流產生一個你不想進入的狀態。你想知道爲了達到你應該進入的狀態而需要的附加事件，並追加它們。田田。
當然，很多這些問題在理論上可以使用事件版本控制，事件模式，快照版本控制等來處理。但是在這一點上沒有事件採購成爲負擔嗎？
不是嗎？是的，您需要爲您的架構設計靈活性，以便您可以積極地演變您的模型，但在覈心上它與存儲當前狀態沒有區別 - 如果必須，您仍然可以遷移。
但你也有其他的槓桿玩。
它的確需要更多的前期設計資本 - 您必須考慮模式生命週期等事情，以及您的記錄冊從您的模型的多個版本中積累數據。
那不是這意味着它是所有腳的鞋。設計好的消息模式是一項投資。如果該架構的消費者（在這種情況下，確實意味着您的模型和用戶）不需要獨立進化，那麼也許這種投資是沒有意義的。