I got this question in my comments section. I’ll try to answer it the best I can, but I might be leaving out good arguments. Who knows..
Why cannot a single model serve reporting, transactions and searching at the same time? I guess it has something to do with scalability and performance of the application to do. What I have read about CQS this far I have not seen any list of all the benefits of it and I have not yet found the real arguments that I can use to convince the other guys in the team.
The main reason for applying the CQS architecture and DDD is to model complex behaviours in your organization. If your only goal is to put a set of forms on top of your relational database, this approach is not for you. In that case you would go with Active Record or Row Data gateway, or smack a MS Access application on top of your database. Also if you wan’t to utilize the CQS Architecture it’s best done in green field projects.
Behaviours and data
In object-oriented programming behaviours are the things the objects can do. If I wan’t to create a scalable object model of my (complex) domain I am interested in exposing the behaviour of my objects and encapsulating the internal state of the object (the data). I aim to keep my object seams as tight as possible. A seam in this context is the exposed interface of my object.
I will now try to explain the difference between exposing data and exposing behaviour.
Let consider the entity “Employee” in a Human Resources Management application. At some point you would like to increase the salary of the employee. In a typical system you would update the “Salary” property on the employee to reflect the changes. Obviously there was a reason for the employee to get his salary changed. Maybe he got promoted, maybe it was just the yearly correction, or maybe he finally completed his master thesis. Let assume the reason was that he finally completed his master thesis. In many companies (at least in Norway) the salary is partly based on education. To capture the new education you would update the “YearsOfEducation” property on the Employee as well. (Simplified, but still.)
The person who is managing the employees need to update different properties in the HRM application to complete his task. Maybe he even has a written note of all the things he has to do in the system in order to update the education of the employee:
In a behaviour centric system this behavior would have been captured by exposing an AddEducation(..) behaviour on the employee. This behaviour (i.e. method) would be responsible for handling all the things that happens when an Employee adds on his education, like getting his salary increased. It would even publish an event so that the salary application could pick up the changes in the employees status.
We want to expose behaviours not data. As a consequence
Setters (i.e public settable properties) are a domain anti-pattern
Since I am interested in modelling behaviours in my domain and keeping a maintainable object model I do not wan’t to expose the data the behaviours is operating upon. This would lead to hard times when I need to change the implementation of my behaviors. As a consequence
Getters are a domain anti-pattern.
To summarize: Do not expose data on your domain model
…and that is the very short answer to why you would have one model for reporting and one for transactions on your domain.
This is the best resource on the web for really getting why you would model behaviour in your application (and yes, I have checked the entire internet): http://herdingcode.com/?p=189
Performance:
I am hoping to go deeper into consistency, partitioning and availability in an upcoming post. Still, what is interesting about the CQS Architecture is that in many cases you can fire off your commands on the domain asynchronously. Fire and forget. You don’t need to wait for the entire processing to have occurred before returning control to your user.
I hope this answers at least some of your questions Anders.
