This question is more of a general question about how to model simple one-to-many relations using collections: should a change in a list item be reflected in the version of the aggregate containing it?
The domain is about meeting scheduling (like in Outlook). I have a Meeting entity, which can have multiple Participants. A participant can accept/decline meeting requests. Rescheduling a meeting nullifies all of the participants confirmations.
I thought of two ways to model this.
Option 1 The Meeting aggregate will contain a list of Participants where each Participant has a ParticipantId and a Status (accepted/denied). The problem here is that every Accept or Deny command, for a specific participant, increments the Meeting's version, which means two participants will enter a race condition if trying to Accept the meeting request based on the same original version. Although this could be solved by re-reading the Meeting's document and retrying the Accept command, it's quite annoying considering how often this could happen. Another approach is to ignore the meeting's version when executing the Accept command, but this introduces a new problem: what happens if, after sending the meeting requests, the meeting has been rescheduled? In this case we can't afford to ignore the Meeting's version, because this time the version DOES represent a real version that should be considered. BTW, is it at all a good practice to ignore the version in some of the commands and not in others?
Option 2 Extract a Participation aggregate out of Meeting. Participation will have MeetingId, ParticipantId, and Status. It will also have its own version. This way, when participant X Accepts the meeting request, only the relevant Participation will be modified, and the rest will be left intact. And, when rescheduling the meeting, a "Meeting Rescheduled" event will be published and an event handler will respond to it by resetting all of the Participations' statuses to "NotAccepted" regardless of their current version. On the one hand this sounds logical in the sense that a meeting's version shouldn't be incremented just because someone accepted/denied its request. On the other hand, modeling Participation as a standalone aggregate doesn't sound quite right to me, because it is has no meaning outside of the context of the meeting.
Anyway, would love to get feedback on this and see the various approaches to this problem.