持久化事件时的 ID 重复（事件溯源）答案

【问题标题】：ID duplication when persisting events (event sourcing)持久化事件时的 ID 重复（事件溯源）
【发布时间】：2016-04-28 20:50:10
【问题描述】：

应用领域驱动设计我读过关于事件溯源的文章。这样可以保存一系列事件。数据库的事件表有以下几列：

EventID, EventDate, AggregateId, EventData

我可以在此表中保存产品、类别和订单事件。但是aggregateId 可能会重复。在这种情况下，我会将订单事件作为产品事件。

如何防止系统 ID 重复。

【问题讨论】：

【解决方案1】：

你不能让 AggregateID 成为 type 和 id 的复合键吗？所以你可以拥有Product:123456 和Category:123456？或者，如果这对您来说是一个更好的解决方案，您可以为聚合类型添加另一列。

【讨论】：

【解决方案2】：

根据定义，聚合根具有全局唯一标识符。如果你正在做 DDD（我假设你是因为你用 DDD 标记了问题），并且你正在使用事件源来捕获聚合根的事件流，那么你需要找到一种方法来确保不同聚合类型的唯一性。

您可以生成 GUID 或使用其他人建议的某种复合键。

【讨论】：

【解决方案3】：

除了使用客户端生成的 GUID 之外，我还建议在表中添加几列。

EventID, EventType, EventDate, AggregateType, AggregateId, MetaData, EventData

出于几个原因，我会添加事件类型和聚合类型。它们将支持底层类型的再水化，允许表上的附加索引，并表示系统中相当重要的信息。最后，它可能会简化对表的读取查询，避免了几个连接。

元数据将允许跟踪用户和/或源事件信息。

尽管这增加了信息以使我可以避免使用复合键，但还是坚持使用 GUID 键。

如果您不能使用客户端 GUID，则可以将 EventID 上的 newsequentialguid() 作为主键。

【讨论】：