I’ve been investigating CQRS recently, trying its interesting stuff like event sourcing, task based UI and other stuff.
I like the idea of separating read/query model from write/business model which separate the real domain from the corruption of querying and data representation in UI, also a big gain in scalability is achieved by the use of event sourcing and separating work load of querying vs commands and operations on the domain.
Although all these stuff are very interesting but it increases the complexity of implementation and adds additional event storage and complicates the architecture a little, so for small to medium applications the Pure Old Domain Driven Design would be more convenient, maybe it could be used in parts of the application as a separate bounded context.
For small to medium less complex solution where PODDD is more convenient I don’t neglect all the idea of CQRS, I try to take some insight from it by separating query model from domain model, and separating query model repository (I prefer to call it Finder) from domain model repository, also the same apply to application layer.
Thus the solution will have one database with two ORM projects, one to map domain entities which are rich business entities, and another project to map query model entities (DTOs) which is more flat and more customizable to presentation or consumer.
The domain model has the domain repository with crud operations with limited read to what is required by domain. and the query model has Finders with many read only queries which returns DTOs and collections of DTOs.
I’m trying to put this architecture into test and analyze the pros and cons, also it is a slight transition phase into more CQRS solution.
Trying to apply it to my Sample and see where is it going.
Tagged: Architecture, CQRS, DDD, Domain Driven Design