依赖于其他聚合的聚合的 EventSourcing答案

【问题标题】：EventSourcing for Aggregates that rely on other aggregates依赖于其他聚合的聚合的 EventSourcing
【发布时间】：2019-01-07 18:57:16
【问题描述】：

我目前正在开发一个以 EventSource 样式编写的日历系统。我目前正在努力解决的是如何创建一个创建许多较小事件的事件，以及如何以允许重播的方式存储其他事件。

例如，我可以触发一个 CreateReminderSchedule，然后触发许多较小事件的构造，例如 CreateReminder。

{
  id:1
  description: "Clean room",
  weekdays:[5]
  start: 01.12.2018,
  end: 01.12.2018
  type: CREATEREMINDERSCHEDULE
}

这将创建大量具有不同 ID 的 CreateReminder 聚合，以便您可以编辑较小的聚合，即

{
  id:2
  description: "Clean room"
  date: 07.12.2018
  type: CREATEREMINDER
  scheduleId: 1
}

所以对我来说，一个问题是当我重播所有事件时，createReminderSchedule 将重新触发 createReminderEvents，这意味着我将在重播期间收到比需要更多的提醒。

是删除较小事件的答案，只需一个大的创建事件，列出事件中提醒的所有 ID，例如：

{
  id:1
  description: "Clean room",
  weekdays:[5]
  start: 01.12.2018,
  end: 01.12.2018
  type: CREATEREMINDERSCHEDULE
  reminderIds:[2,3,4,5,...]
}

但如果我这样做，那么我的所有提醒聚合都不会有基本事件。

请注意，提醒必须知道提醒计划，以便我以后可以更改提醒计划以更新与该提醒计划相关的所有提醒

【问题讨论】：

不应该由您的消费者负责处理这个吗？您在这里所做的只是发布event 事件。然后，您的 listener 应该尽其所能删除重复的事件。
@AnkitVijay 这就是问题所在。当在创建这些事件时生成新的较小事件 (createReminders) 的 id 时，此侦听器如何知道是否存在重复事件。我认为一个建议是让 createScheduleReminder 存储即将生成的 id。但这感觉有点不合时宜。
不管你在发布端做什么，我认为你的监听器无论如何都应该处理重复的事件。（例如：如果用户发送相同的请求两次并且CreateReminderSchedule 被触发超过一次？）如果这意味着您需要存储生成的 ID，那就这样吧。

标签： domain-driven-design event-sourcing aggregateroot

【解决方案1】：

也许您将事件与命令混淆了。您可以有一个命令被处理以创建您的提醒（以事件的形式，即 ReminderCreated），然后将其应用于您的聚合以创建您的提醒对象。每次从源重放事件时，都会以相同的方式重新创建此状态。

【讨论】：