Domain Driven Design and Data Conflicts

Question

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).

Answer 1

I suppose that if resolving data conflicts is a part of technical considerations which you cannot remove, then whatever is required to resolve such conflicts does belong to the domain.

You could have two interface layers for that, though.

The simpler layer, oblivious of conflict-resolution needs, can be used wherever conflicts cannot arise (e.g. querying and visualization), and be published more widely.

Its more complicated superset, the one which allows to see and resolve conflicts, can be used only where conflicts can happen (e.g. updating or replication logic), and be constrained to that narrower area. If you rework the conflict-handling logic, the clients that don't work with conflicts will not notice it and will not need an update.