The last year I have been working at a customer creating a product with a fairly complex domain model. We started of by using a DDD approach, creating a domain model, repositories, domain services, application services, thinking bounded context, using aggregates and aggregate roots. The application were based on recommendations from Evans book. Everything worked pretty well, except for one thing; we had to do a lot of mapping between the “layers” in the application. Some of it couldn’t be avoided, and luckily some of it could. One thing that bugged me was all the effort we had to go through just to show some data in the GUI.
When showing data, the data had to be dragged through all the “layers”. This felt a bit meaningless because the data didn’t have to be validated in any way, and they for sure didn’t touch any business rules on their way up.
We then started to look for other solutions, and discovered Command Query Responsibility Segregation. In CQRS the application is split into to parts; one where you only can query for data and one you only can write data. I wont go into the technical parts of how this is done in this post, but rather focus on what it have given us concerning productivity. Instead of having to focus on pulling data through n-layers just to show the data in the UI, we could put our effort into creating a more user friendly UI and and focus on important things like cranking out more functionality for the product owner. The commands in CQRS fell naturally into the ubiquitous language and it made us focused on the what the user really wants when he executes a action in the GUI.
And maybe one of the best things are that we still used the good practices from Domain Driven Design in our application. We have of course had problems, but all in all we have had more positive effects than negative.
Anyone had a similar experience?
Tags: cqrs