EventSourcing for Aggregates that rely on other aggregates

Question

I'm currently working on a calendar system written in an EventSource style. What I'm currently struggling with is how to create an event which create lots of smaller events and how to store the other events in a way which will allow them to be replayed.

For example I may trigger an CreateReminderSchedule which then triggers the construction of many smaller events such as CreateReminder.

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

This will then create loads of CreateReminder aggregates with different ids so you can edit the smaller ones i.e.

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

So to me one problem is when I replay all the events the createReminderSchedule will then retrigger createReminderEvents which mean I'll have more reminders than needed during the replay.

Is the answer to remove the smaller events and just have one big create event listing all the ids of the reminders within the event like:

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

But if i do this way then I won't have the base event for all my reminder aggregates.

Note the reminders must be aware of the reminderSchedule so I can later change the reminderSchedule to update all the reminders related to that reminderschedule

Should not the responsibility lie on your consumer side to handler this? What you are doing here is just publishing the `event` occurrence. Then, your `listener` should do what it takes to remove duplicate events. — Ankit Vijay, Dec 23 '18 at 21:46
@AnkitVijay this is where the problem may lie. How would this listener know if there are duplicate events when the id for the new smaller events (createReminders) are generated at the point of creating these events. I think one suggestion is for the createScheduleReminder to store the upcoming generated ids. But that feels a bit of a hack. — Harry, Dec 28 '18 at 11:48
irrespective of what you do on the publish side, I think your listener should take care of duplicate events anyways.(For example: what if user sent the same request twice and `CreateReminderSchedule` is triggered more than once?) If this means that you need to store the generated ids so be it. — Ankit Vijay, Dec 28 '18 at 21:06

score 1 · Answer 1 · answered Jan 07 '19 at 10:57

Perhaps you are confusing events with commands. You could have a command that is processed to create your reminders (in the form of events, ie ReminderCreated) which is then applied to your aggregate to create your reminder-objects. This state is recreated in the same way every time you replay your events from its source.

EventSourcing for Aggregates that rely on other aggregates

1 Answers1