仅附加事件存储是否会导致仅附加代码库？

Question

在使用事件源实现应用程序时，工作中的持久性引擎是一个事件存储。也就是说，事件的附加日志，过去时，顺序或发生。只需通过应用程序重放事件，即可再现任何时间点的状态。

我的担心 - 这个 append-only 事件存储是否不可避免地导致 append-only 代码库？如果删除甚至更改代码可能会使应用程序无法重播事件序列，您如何维护代码库？源代码行数能减少吗？

如果必须修改业务规则，或者更糟糕的是，如果应用程序早期的一个讨厌的错误允许它进入禁止状态怎么办？错误的代码必须无限期地保持活动状态吗？当然，理论上，这些问题中的许多问题都可以使用事件版本控制、事件模式、快照版本控制等来解决。但在这一点上，事件溯源难道不是一种负担吗？

事件溯源是一项相当新的技术，至少在生产中是这样。我怀疑很少有应用程序已经在它上面运行了几年以上。 10年后它们会是什么样子？对于企业应用程序来说，这不是一个不切实际的时代。

Answer 1

我的担忧——这种仅附加的事件存储是否不可避免地导致了仅附加的代码库？

不，它意味着一个仅附加的模式，它与您的实现分离。

如果必须修改业务规则，或者更糟糕的是，如果应用程序早期的一个讨厌的错误允许它进入禁止状态怎么办？错误代码必须无限期地保持活动状态吗？

并非如此 - 域与持久表示分离。

是的，您需要将一些常见场景融入您的设计中；就像您可能需要在事件历史记录的早期补偿错误的想法。

从根本上说，这与仅存储当前状态的情况没有什么不同。如果您的数据库中有一个聚合表示处于错误状态，您只需将其更新到位，对吗？通过将某些字段更改为应有的内容。

事件溯源的想法是一样的；您有一个事件流，它产生了您不想处于的状态。您找出达到您应该处于的状态所需的额外事件，并附加它们。多田。

当然，理论上，很多这些问题都可以使用事件版本控制、事件模式、快照版本控制等来解决。但是在这一点上，事件溯源难道不是一种负担吗？

真的没有？是的，您需要在架构中设计灵活性，以便您可以积极地发展您的模型，但其核心与存储当前状态没有什么不同 - 如果需要，您仍然可以迁移。 p>

但您还可以使用其他杠杆。

它可能确实需要更多的前期设计资本 - 您必须考虑诸如架构生命周期之类的事情，以及您的记录簿从模型的多次修订中积累数据这一事实。

这并不意味着它是适合所有脚的鞋子。设计好的消息模式是一项投资。如果该模式的消费者（在这种情况下实际上意味着您的模型和订阅者）不需要独立发展，那么也许这种投资没有意义。