I realise it is probably overkill for what is a occasionally connected client app, but the construction of aggregates roots is bugging when thinking about it from a client perspective.

For the purposes of providing domain visualisation, let’s just say that whole system is concerned with arranging and editing meetings with customers.

Now, the domain model is set up fine and is able to define itself properly OUTSIDE of the need to interface with another system. However, uploading client data to an external system can result in in Data conflicts (update, delete, etc) which in turn will raise UserAlerts. These will require action from the client user in order to resolve. (eg Viewing the two records before merging and saving into one).

So firstly, it strikes me that the main domain model’s overall purpose is quite distinct from the need for a user to resolve a data conflict. So in this sense, I would expect UserAlerts to be separate from the meeting aggregate.

However, resolving an alert will surely need to be conducted within a transaction, since the alert itself should not exist without the meeting object. So in this sense, it seems that it would make sense for the alert to be contained within the aggregate.

So, I am confused with regards to this. Has anyone out there modeled a similar situation? (I have a temporary solution in place already, but I would just like to know what people think is the correct way of doing things).