I got thinking today about what action to take in the scenario where I want to have unique constraints on a value. To put into some context, I will use forums and the like to explain. A Forum has threads and it is necessary that each Thread have a unique title/topic within the scope of the parent Forum. Now my model for a forum does not have a collection of Threads in it as over time, this would get really tricky if the number of threads got large. Although if I did have a collection of threads on the Forum model itself, I would easily be able to constrain the title/topic of the Thread, as I would have the titles/topics readily available for comparison.
So, I have access to the Threads collection inside the Repository due to the potential size of the collection. The next thought which comes into my head was using the Reporting layer to check the constraint, but something didn’t feel right. Anyways I did some googling and came across a http://stackoverflow.com question which in turn led me back to this article from Udi Dahan, http://www.udidahan.com/2009/12/09/clarified-cqrs/ . The http://stackoverflow.com showed me the following quote from the article by Udi Dahan:
Also, we shouldn’t need to access the query store to process commands – any state that is needed should be managed by the autonomous component – that’s part of the meaning of autonomy.
Using the reporting layer for this purpose shouts race conditions to me and as a result break the unique constraint due to the timing a Thread (of a Forum) with the same name could be added in two separate sessions before the reporting layer can report the first. This probably falls in the realm of eventual consistency and a compensating event will need to be raised to correct this. At time of writing I am not sure which layer would have the knowledge to raise this event as it would, for example, only occur on the reporting side if a rdbms column constraint failed.
How about integrating the notion of constraints into the domain model. I think it would be feasible to allow the inspection of each constraint in the model. In this way there is no dependency to the Reporting Layer and full control remains inside the domain. This does mean ofcourse that is the value of an object changes and the value is constrained, then the constraints data store would have to be updated. To clarify, I am saying that the retrieval and update of this value is done from the domain model persistence layer and not from reporting layer. I like the idea of responding to events inside the domain layer before such events are published.
One example, which I want to write a small project to demo and possibly show myself the downside of this is how I would see the signature of one of the methods on the Thread Domain Model:
void AddThread(Thread thread, IConstraintsChecker<Thread> constraintsChecker);
Cheers,
Andrew