Context: the product I'm working on is moving away from a monolith to a modular monolith architecture, and in the process implementing DDD concepts, as well as a more event-driven architecture.
Problem: a lot of operations are set-oriented (i.e. they accept a set of Items instead of a single one). From what I understand, this is a violation of the Aggregate rule of "one Aggregate change per transaction", however Vaughn Vernon mentions in IDDD (p. 367/368) that "UI convenience allowing the user to create batch Aggregates" (paraphrased) is one of the "accepted reasons" to break this rule. There is no mention on what the corresponding events would look like.
Question: Would it be correct, in this particular case, to batch all the ItemCreated events in a single ItemsCreated events (plural vs singular), with all the individual events as payload?
So, if the user creates 10 Items at once, instead of having 10 ItemCreated (singular) events, I would have a single ItemsCreated (plural) event, with the 10 Items referenced.
Other notes: I understand that Domain Events are emitted by Aggregates, and as such there should be a 1:1 match between event-emitting commands and Domain Events. I am not sure if this batching of Events can be accomplished away from the Aggregates.
I understand that Domain Events are emitted by Aggregates, and as such there should be a 1:1 match between event-emitting commands and Domain Events.
There are a number of people who feel quite strongly that one "transaction" should necessarily mean one "event". I've argued with some of them. They aren't particularly convincing; but apparently neither was I.
1:1 is simple - but you have to be careful about the cases where you pay for simple with more complexity somewhere else.
Would it be correct, in this particular case, to batch all the ItemCreated events in a single ItemsCreated events (plural vs singular), with all the individual events as payload?
It could be (but I would guess that it won't be).
What I think you should do is look into the nuance of the situation more carefully - within the business domain that you are modeling, is this really one thing that's going on, or is it 10 different things that just happen to be coincident in time because they were delivered together?
Does everybody who cares about one of the items in this set necessarily care about all of them?
If you were to implement "create 10" as two distinct "create 5"s, would that call for one event? two events? 10 events?
The fact that you are considering these to be 10 different aggregates (as opposed to one aggregate with 10 different entities within it) suggests that we really do have 10 different acts of creation that the business cares about.