Event Sourcing - Multiple events or a single for a change on one aggregate?

Question

I have a checklist system where we are implementing CQRS/ ES (Event Sourcing). We have a command

updateStatus(taskId: string, status: boolean)

to mark a task or sub task as completed. If I receive a command that a sub task is completed, and all the sibling sub tasks are also completed, I have to mark the parent task as completed as well. So in the example below (subtasks 1-3 of task A):

• [ ] task A - open
  • [ ] task 1 - open
  • [*] task 2 - completed
  • [*] task 3 - completed

Tasks A and 1 are both open initially and then I receive a command

updateStatus(task1, completed)

the CommandHandler needs to generate an event taskCompleted(task1).

My question is what is the correct CQRS/ ES requirement:

• Generate a single event: taskCompleted(task1)
• Generate two events: taskCompleted(task1), taskCompleted(taskA)

In the first option I would expect the consumers of events to see that the aggregate should also update itself to be completed. In the second, the command handle takes care of it.

The major downside of option 1 is more processing for command handlers and their deeper knowledge of the aggregate. Another disadvantage is re-use of the events (e.g. say we have logic for sending an email to task owner when it is completed, with option 2 there would simply be a second event handler which just listens to events and acts on them without knowing the full logic).

The major downside of option 2 is a much larger number of events.

Any suggestions on which is the more correct approach using CQRS/ ES?

Answer 1

Short answer: You should generate two events.

A single command invocation can lead to multiple events, so generating more of them really isn't an issue. But why exactly would you want to do that in your case? To prevent scattering of responsibility.

In a very basic event sourced project I can imagine there are at least two working parts to your application:

1. event sourced models,
2. projectors updating the read side of your application to generate data for reading.

If you generated only one event - that a subtask has been completed, you will now need to introduce logic to your projectors, to make a parent task also completed upon completing all subtasks. You are duplicating domain logic, because the same will also live in your write/domain layer, to complete the parent task aggregate upon completion of all subtasks. On top of that, it's quite likely such logic would be written in a completely different language than your domain, e.g. in SQL if your read models are in a SQL database.

If your application is at the stage I have described (i.e. write side with read side projectors), you might say that duplicating the domain logic is not really an issue. After all, in a lot of projects a SQL implementation may include domain rules, too. The problem becomes more apparent when your application grows and/or is perhaps even split between microservices.

If you add a notification microservice which should notify all watchers of a task when the task is completed, with a single event (of subtask completion) your way of determining task's completeness would once again copy the task's domain logic - checking it's local database whether all subtasks are already completed. What makes this even more complicated, unlike projectors, this microservice is very likely to live in a totally different project, apart from the microservice project containing task management. This makes it extremely difficult to track broken domain logic, which is not scattered across your entire infrastructure.

With two events, marking a parent task in a projector is as simple as doing:

fun changeTaskToCompleted(event: TaskCompletedEvent) {
    database.executeUpdate('UPDATE task SET completed = true WHERE id = ?', event.taskId)
}

and in your notification microservice the implementation is also greatly simplified by only reacting to the TaskCompletedEvent:

fun processEvent(event: Event) {
    when(event) {
        is TaskCompletedEvent -> sendTaskCompletedNotificationEmail(event)
    }
}

Answer 2

In addition to the points raised in the answer by @Andy, if you have two events, you can arrange your code such that the check if all sibling tasks are completed is moved to an event handler.

This would make the flow of actions

1. Command handler receives updateStatus(task1, completed)
2. Command handler emits event taskCompleted(task1)
3. TaskCompleted event handler receives event for Task1
4. Event handler sees all sibling tasks are completed
   • Event handler issues command updateStatus(taskA, completed) to the command handler, or
   • Event handler emits event taskCompleted(taskA)

This way, the command handler doesn't even have to know about the completion of parent tasks when all sub-tasks are completed. That is all handled in a dedicated event handler.

Answer 3

The major downside of option 2 is a much larger number of events.

Any suggestions on which is the more correct approach using CQRS/ ES?

Having multiple events for different things that happened is not a downside but improves your design. With that the logic of interpreting the change of the data to express what happened from the business perspective is encapsulated in your service and does not leak outside to several projectors. Andy's answer has already explained this very well.

And of course it is totally fine to generate several events after a single command has been executed. It is an implementation detail how the subsequent events will be triggered.

A SubTaskCompleted event could trigger some other code that checks if the all sub-tasks of the task are completed now and then trigger the TaskCompleted event. But it could also be within the same method that executes the command that you determine both events that should be emitted due to the completion of the sub-task.

Note: I would not trigger subsequent SubTaskCompleted events when the whole main task was completed with a separate user interaction because such sub-task progress is no longer interesting when a whole main task was checked as completed. As events should reflect what really happened in the system if you mark a main task completed with a single click it would not make sense to produce sub task completed events for all corresponding sub-tasks from my point-of-view.

Alltough your question and the answers strongly focused on the events (which is good of course) I just want to point out that I see some potential smell concerning your command:

We have a command

updateStatus(taskId: string, status: boolean)

to mark a task or sub task as completed.

I'm pretty sure that updateStatus does not reflect your business language and thus has no strong meaning in your domain.

I would rather suggest to change your command to

completeSubTask(taskId: string)

This gives your command strong meaning which not only expresses the business logic a lot better but also fits to your events. In addition, I have often seen commands/methods starting with a boolean flag and afterwards being changed to a lot more parameters which makes harder and harder to understand the corresponding business logic.