Chapter 9 - An Event is just a fact, pure
Surely you remember that, in modeling the Student aggregate and the Course aggregate, we defined some events that looked like duplicates:
They were necessary to validate the respective invariants of the course and the student during the subscription process. If we had a weird feeling during the event storming phase, the feeling doesn't improve later. Indeed, reading the content of the event store, we can notice that for each subscription, there are two close events with the exact same content!
They differ only because they originate from one or another aggregate (represented here by the colors red and green). How can we get rid of this?
append(DomainEvent events, StreamQuery query, EventIdentifier lastEvent)
For example, if after a student is subscribed, the course reaches its maximum capacity, I may want to publish the CourseFullyBooked Event in the same transaction. The StudentSubscribedToCourse Event will be associated with both the student and the course, while the CourseFullyBooked Event will be associated only with the course: