13

我目前正在尝试了解如何构建事件存储的内部结构。到目前为止我得到了什么：

  • 一个事件存储有两个表（集合，...），一个用于聚合，一个用于事件。
  • 聚合表包含以下数据：（aggregateId可能是一个 GUID）和aggregateVersion（它是一个整数，仅表示影响此聚合的最后一个事件的数量）。
  • events 表包含以下数据：（eventId同样是一个 GUID）、aggregateId（事件所属的）payload、 和 a version（它是一个简单的整数，用于描述事件的顺序）。

到目前为止这是正确的吗？是否应该使用整数对事件进行排序？还是应该根据时间戳对它们进行排序？各有什么优势？有什么缺点？

4

4 回答 4

10

我建议您查看Jonathan Oliver 的 EventStore以供参考。

在 SQL 持久化版本中，只有一张表。您可以轻松地在没有聚合表的情况下生活，并将聚合 ID 存储在事件表中。可以使用 max() 查询来检索最新版本。

除此之外，我认为您应该考虑在事件表中包含标题，因为总是有一些有趣的元数据您不想存储在事件本身中。

而且，我认为您应该在事件表中添加一个日期列。

最后，您可能希望有某种标志来说明事件是否已被下游调度。此添加使您能够在一个线程或进程中写入并在另一个中分派。

Aaand 那里，我有点建议 Jonathans EventStore 的结构。

于 2012-09-21T12:19:53.277 回答
4

查看http://geteventstore.com/ - Greg Young 的这个版本也有可供您阅读的源代码 [在 GitHub 上有 BSD 3 条款许可证]。

于 2012-09-21T12:18:19.433 回答
4

我不能为 Mikael 的回答添加太多内容。

这里还有一件事可以作为参考：几年前，Greg Young 写下了他对事件存储实现的想法。该文档可在http://cqrs.wordpress.com/documents/building-event-storage/找到

尽管我相信他的方法在此期间也有所发展。

于 2012-09-22T05:28:34.220 回答
2

聚合与 cqrs 相关，但不直接与事件存储相关。没错，有两个集合，但它们是事件和快照。有关更多详细信息，请查看： https ://github.com/jamuhl/nodeEventStore

于 2012-09-21T12:20:27.237 回答