在实现具有事件源的应用程序时，工作中的持久性引擎是事件存储。也就是说，按事件或事件的过去时，事件的追加记录。通过简单地通过应用程序重播事件，可以再现任何时间点的状态。附加事件存储是否会生成仅附加代码库？
我担心的 - 没有这个追加只事件存储不可避免地导致追加只代码库？如果删除甚至更改代码可能会使应用程序无法重播事件序列，那么如何维护代码库？代码的源代码行数是否会减少？
如果必须修改业务规则，或者更糟糕的是，如果应用程序初期早期的恶意程序错误允许它进入禁止状态会怎么样？错误的代码必须无限期地保持活着吗？当然，理论上来说，很多这些问题都可以通过事件版本控制，事件模式，快照版本控制等来处理。但是，在这一点上，事件采购不会成为负担吗？
事件采购是一项相当新的技术，至少在生产中。我怀疑已经运行了几年的应用程序已经很少了。他们在10年后会是什么样子？对于企业应用程序来说这不是一个不现实的时代。
我的问题 - 这个只能附加事件存储不可避免地导致只有附加代码库吗？
不，它意味着一个附加的模式，它与您的实现分离。
如果业务规则必须修改，或者更糟糕的是，如果应用程序的早期早期的恶意错误允许它进入禁止状态会怎么样？错误的代码必须无限期地保持活着吗？
不是真的 - 域与持久表示是分离的。
是的，您需要将一些常见方案合并到您的设计中;就像您可能需要补偿事件历史中的错误。
如果您只是存储当前状态，那么它与您所做的基本上不同。如果您的数据库中的聚合表示处于错误状态，则只需更新它就行了吧？通过改变一些领域到他们应该是什么。
这个想法在事件采购中是一样的;你有一个事件流产生一个你不想进入的状态。你想知道为了达到你应该进入的状态而需要的附加事件，并追加它们。田田。
当然，很多这些问题在理论上可以使用事件版本控制，事件模式，快照版本控制等来处理。但是在这一点上没有事件采购成为负担吗？
不是吗？是的，您需要为您的架构设计灵活性，以便您可以积极地演变您的模型，但在核心上它与存储当前状态没有区别 - 如果必须，您仍然可以迁移。
但你也有其他的杠杆玩。
它的确需要更多的前期设计资本 - 您必须考虑模式生命周期等事情，以及您的记录册从您的模型的多个版本中积累数据。
那不是这意味着它是所有脚的鞋。设计好的消息模式是一项投资。如果该架构的消费者（在这种情况下，确实意味着您的模型和用户）不需要独立进化，那么也许这种投资是没有意义的。