16

事件溯源被认为是许多事情的奖励，例如事件历史/审计跟踪、完整和一致的视图再生等。听起来很棒。我是粉丝。但这些都是读取端的实现细节，您可以通过将事件存储完全移动到读取端作为另一个订阅者来完成相同的操作。为什么不呢？

这里有一些想法：

  1. 视图/非规范化器本身并不关心事件存储。他们只是处理来自域的事件。
  2. 将事件存储移动到读取端仍然可以为您提供事件历史记录/审计
  3. 您仍然可以从事件存储中重新生成视图。除了现在它不必是写入模型泄漏。给他读模范公民！

这似乎是将其保留在写入端的一个技术论据。这是来自http://codebetter.com/gregyoung/2010/02/20/why-use-event-sourcing/的 Greg Young 的：

然而，使用存储当前状态快照的东西存在一些问题。最大的问题围绕着您向数据引入了两个模型这一事实。您有一个事件模型和一个表示当前状态的模型。

我觉得有趣的是术语“快照”，它最近也成为事件溯源中的一个显着术语。在写入端引入事件存储会增加加载聚合的一些开销。您可以争论多少开销，但这显然是一个感知或预期的问题，因为现在有从快照加载聚合和自快照以来的所有事件的概念。所以现在我们又有了……两个模型。不仅如此，我看到的快照建议旨在作为基础设施泄漏来实现，后台进程会遍历整个数据存储以保持性能。

在拍摄快照后，快照之前的事件从写入的角度来看 100% 无用，除了……重建读取端！这似乎是错误的。

另一个与性能相关的话题：文件存储。有时我们需要将大型二进制文件附加到实体。从概念上讲，有时这些与实体相关联，但有时它们是实体。将这些放在事件存储中意味着您必须在每次加载实体时物理加载该数据。这已经够糟糕的了，但想象一下其中有几个或数百个这样的大集合。我看到的每个答案基本上都是咬紧牙关并将uri传递给文件。这是一种逃避，会破坏分布式系统。

然后是维护。重建视图需要一个涉及事件存储的过程。因此，现在您编写的每个视图维护任务都进一步将您的写入模型绑定到使用事件存储......永远。

CQRS 的重点不是围绕读模型和写模型的用例根本不兼容吗？那么为什么我们要把读模型的东西放在写端，牺牲灵活性和性能，然后再把它们耦合起来。为什么要花时间？

所以总而言之，我很困惑。在我所坐的所有方面，事件存储作为读取模型细节更有意义。您仍然可以获得保留事件存储的许多好处，但您不会过度抽象写入端持久性，这可能会降低灵活性和性能。而且您不会通过泄漏的抽象和维护任务将您的读/写端耦合起来。

那么有人可以向我解释一个或多个令人信服的理由将其保留在写入方面吗？或者，为什么不应该将其作为维护/报告问题放在读取端？同样，我不是在质疑商店的实用性。就在它应该去的地方:)

4

3 回答 3

14

这是一个长期死的问题，有人指出我。有很多原因可以更好地在写入端存储事件。

据我了解，您所谈论的架构是我看到的一种非常常见的架构……失败了。我们将域模型存储在关系数据库中，然后输出事件。您添加它们的扭曲，将读取端的事件保存在事件存储中。这很可能会导致混乱。

您将遇到的第一个问题是发布您的活动。当我保存到数据库并发布到 MSMQ 时会发生什么（我死在中间）。因此在它们之间引入了 DTC。这是一件大事，应该像瘟疫一样避免分布式事务。它也非常低效，因为我可能使数据持久化两次（一次排队到数据库）。这将大大限制系统吞吐量（200-300 条消息/秒的 DTC 基准​​很常见，而事件只有 20-30k/秒是常见的）。

有些人通过在他们的数据库中放置一个包含事件并作为队列操作的表来解决对 DTC 的需求。这将避免对 DTC 的需要，但这仍会遇到下一个问题。

当你有错误时会发生什么？我知道您永远不会编写有错误的代码，但后来有一位 Jrs/维护开发人员使用该项目。例如，当域对象更改和引发的事件不匹配时会发生什么？假设您将域对象上的状态设置为“LA”（硬编码），但您正确地将事件上的状态设置为 cmd.State（“CT”）。

您将如何检测正在发生的此类错误？正在讨论的最大问题是现在有两个“真相”来源，即写入端的数据库和出现的事件流。没有办法证明它们是等价的。这将导致各种奇怪的错误。

于 2013-04-19T10:51:04.127 回答
5

我认为这确实是一个很好的问题。将您的聚合视为一系列事件在写入方面本身很有用，使命令重试等更容易。但我同意创建事件似乎令人不安，然后如果您需要这种快照性能改进，则必须为持久性创建另一个对象模型。

我认为聚合仅存储快照但将事件发送到读取模型以投影到读取模型的系统将被称为“CQRS”，而不是“事件溯源”。如果您保留事件以进行重新投影，我想您将拥有一个两者兼而有之的系统。

但是你不会有三个定义吗？一种用于持久化聚合，一种用于传达状态更改，还有更多用于回答查询？

在这样的系统中，通过加载聚合并直接向他们提问来开始回答查询是很诱人的。虽然这不是以任何方式禁止的，但它确实倾向于开始导致这些聚合增加他们可能不需要的功能，更不用说复杂的线程和事务了。

于 2012-05-15T01:34:50.963 回答
3

将事件存储放在写入端的一个原因可能是在事件成为“事实”并被分发/分派之前解决并发问题，例如通过对提交事件流的乐观锁定。这样，在写入方面，您可以确保解决对同一事件流（聚合）的并发“提交”，其中一个通过，另一个必须通过比较事件或传播以智能方式解决冲突与客户端发生冲突，从而拒绝该命令。

于 2012-05-24T15:44:59.520 回答