使用事件源实现应用程序时，工作中的持久性引擎是事件存储。也就是说，在过去时，按顺序或事件的仅附加事件日志。通过简单地通过应用程序重放事件，可以再现任何时间点的状态。
我担心 - 这个仅附加事件存储不会导致仅附加代码库吗？如果删除甚至更改代码可能会使应用程序无法重放事件序列，那么如何维护代码库？源代码行的数量是否会减少？
如果必须修改业务规则，或者更糟糕的是，如果应用程序早期的一个令人讨厌的错误允许它进入禁用状态会怎么样？错误的代码必须无限期地保存下来吗？当然，理论上很多这些问题都可以使用事件版本控制，事件模式，快照版本控制等来处理。但是当时没有事件来源成为负担吗？
事件采购是一项相当新的技术，至少在生产中是这样。我怀疑很少有应用程序在其上运行超过两年。 10年后他们会是什么样子？对于企业应用来说，这不是一个不切实际的时代。
答案 0 :(得分：1)
我担心 - 这个仅附加事件存储不会导致仅附加代码库吗？
不，它意味着仅附加架构，它与您的实现分离。
如果必须修改业务规则，或者更糟糕的是，如果应用程序早期的一个令人讨厌的错误允许它进入禁用状态会怎么样？错误的代码必须无限期地保持活着吗？
不是 - 域与持久表示分离。
是的，您需要将一些常见的场景纳入您的设计中;比如您可能需要在事件历史记录的早期补偿错误。
从根本上说，它与你只存储当前状态时所做的不同。如果您的数据库中的聚合表示处于错误状态，那么您只需将其更新到位，对吧？通过将一些字段更改为它们应该是的字段。事件采购的想法是一样的;你有一个事件流产生一个你不想进入的状态。你弄清楚到达你应该进入的状态所需的其他事件，并附加它们。多田。
当然，理论上很多这些问题都可以使用事件版本控制，事件模式，快照版本控制等来处理。但是，当时没有事件来源成为负担吗？
不是吗？是的，您需要为您的架构设计灵活性，以便您可以积极地改进您的模型，但在它的核心，它与存储当前状态没有区别 - 您仍然可以如果必须，请迁移。
但你也可以使用其他杠杆。
它可能需要更多的前期设计资本 - 您必须考虑诸如模式生命周期之类的事情，以及您的记录簿累积来自模型的多个修订版的数据。
并不意味着它是一双适合所有人的鞋子。设计好的消息模式是一项投资。如果该模式的消费者（在这种情况下真的意味着您的模型和订阅者）不需要独立发展，那么这种投资可能没有意义。