问：“如何使客户方便使用事件溯源Eventsourcing？”
答：“只要不告诉他们，他们应该不在乎”
更多答案：
我有一个合理的经验法则来决定您的业务领域是否适合事件溯源：是否涉及律师，会计师或审计师？
历史记录在物联网，运输，商业，ERP，CRM，旅行，任何形式的预订等方面都非常有价值。
经过10年的电子商务，在金钱或其他一切有风险的事情上，我总是会选择ES。
我认为将事件源与历史记录收集用于审计目的有点误导。如果您没有很好定义/稳定的事件格式，更改要求或有时需要及时返回（例如，不是“仅追加”），则从事件重播会更加困难。
历史可以像版本化文档一样保存。但是捕获系统行为是非常宝贵的。
我想知道我们是否在这里缺少一些假设前提，可能的前提是，在使用ES并将系统投入生产之前，您已经对领域和稳定的业务模型具有公认的，非常好的理解？因为我的经验是，这比听起来要难。
我同意，由于范式的不断变化和基本模型的变化，对于不断发展的业务而言，未经验证的领域模型对事件源来说是一团糟。但这并不经常发生。我今天在会议上提到了它。
我的经验是，ES系统实际上比传统系统更容易发展。在传统系统中，我们通过假装旧数据发生在新模型中进行迁移。这种迁移是痛苦的，昂贵的，有风险的，并且通常是不可逆的。我们刚好习惯了那种痛苦。或者我们只是不迁移，而只是添加更多的差劲CRU操作，直到它变成无法理解的遗留混乱，这也是我们习惯的痛苦。在ES中，更改是明确的：我们将旧数据保留在旧模型中。该事件在此时间点在此模型下运行，没有任何影响。另一个好处：我们的事件历史记录可以跟踪模型更改。GDPRWasActivated是一个域事件，UpgradedCustomerToNewMobilePlan也是如此。模型更改成为模型本身的第一流。同样，有明确的基本复杂性。
banq注：当有多个来源更改一个状态，比如设置为true或false，如果你将这个状态字段设计到数据库表中，那必须所有来源都需要知道有这个表字段，一旦表结构改变，影响全面。但是使用事件溯源，无论内部自己的操作，还是加载的第三方插件，或者调用第三方API，所有修改聚合状态的事件都会被放入事件日志，那么我们关心的状态是true和false可以从这个事件日志中追溯到，也许这是过了N多年以后的事情。