事件溯源：聚合根和性能

Question

我正在使用事件溯源构建一个StackOverflow克隆版。MVP很简单:

1. 用户可以发布问题
2. 用户可以回答问题
3. 用户可以为未关闭的问题投票

我将问题建模为聚合根。一个问题可以有零个或多个答案，而一个答案可以有零个或多个赞和踩。

然而，这导致了一个巨大的性能问题。要点赞一个答案，必须加载问题（作为聚合根），这需要加载所有答案。在非事件溯源DDD中，我会使用延迟加载来解决这个问题。但是在事件溯源中进行延迟加载是不容易的 (http://docs.geteventstore.com/introduction/event-sourcing-basics/)。

将问题建模为聚合根是否正确？

- MattTannahill

---

弗农似乎建议应该有多个聚合来避免并发问题：http://ptgmedia.pearsoncmg.com/images/9780321834577/samplepages/0321834577.pdf - MattTannahill

不，你没有建模聚合根。你“建模”了一个数据结构/视图模型，并将其称为“聚合根”。正确的DDD不会有这个问题，这是最常见的DDD错误之一。你的模型是完全错误的，你需要重新尝试识别聚合和它们的一致性规则。顺便说一句，通常CQRS是提高性能的答案，但在这种情况下，无论是否使用CQRS，模型仍然是错误的。 - MikeSW

感谢反馈。我发现 Vaughn Vernon 的这个例子非常有帮助：https://github.com/VaughnVernon/IDDD_Samples/tree/05d95572f2ad6b85357b216d7d617b27359a360d/iddd_collaboration/src/main - MattTannahill

你可能想使用快照而不是延迟加载。http://cqrs.nu/Faq/event-sourcing - inf3rno

Answer 1

首先，在使用ORM时不要使用懒加载。你可能会发现自己处于比等待更糟糕的情况中，如果你需要使用它，大多数情况下意味着你的模型是错误的。

你可能想考虑以下几点：

1. 你期望有多少回答。 2. 如果有人在你提交答案时发布了答案，或者赞同了答案，会发生什么。 3. 赞同是否只是简单的+1，你不再关心它，或者你可以找到用户的所有赞同，例如将它们更改为反对票（赞同已被识别）。

你可能想要分开聚合，不是因为性能问题，而是因为并发问题（第二个问题）。

根据性能和你的赞同行为方式，你可能想将其建模为值对象（第三个问题）。

请参阅read ithttp://dddcommunity.org/library/vernon_2011/ 通过使用cqrs读/写分离，您可以实现真正的性能提升。http://udidahan.com/2009/12/09/clarified-cqrs/

- Dariss

---

感谢提供Vernon的技巧。他的书非常有启发性，GitHub上的示例也是极大的帮助。 - MattTannahill

Answer 2

使用简单的读模型应该不会有问题。您期望一个问题的最大答案数量是多少？也许只有几百个，这对于非规范化数据模型来说并不是什么大问题。

点赞事件将由一个非常简单的命令触发，具有少量属性。

事件处理程序很可能需要加载整个问题。但是通过聚合根ID加载这些记录并重放事件非常快速。如果每个问题的事件数量变得非常高（由于答案编辑等原因），则可以实现快照而不是重放每个单独的事件。而且该过程是异步完成的，这将使读模型与事件存储“最终一致”。

- Dmitry S.