As I understand CQRS advocates separating read models from domain models and having a particular read model for every necessary domain model projection.
From usage point, how the read model is stored and retrieved should be transparent – you issue a query and get a read model without caring about how it is made.
Many examples and articles use separate tables for storing read models and re-generating them by response to domain model changes.
I do not really like this approach because of the following reasons:
- Not all possible read models will be needed often;
- Requirement changes might invalidate existing read models so all of them will need to be regenerated;
- If for some reason read model contains properties that cannot be stored on generation but need to be calculated you are forced to use stored procedures/functions/views;
- Since read models are separate from domain models in case application-level caching is used on domain model change you need to inform all applications that old read models need to be evicted from cache;
- Sometimes it is not possible nor desirable to denormalize complex object graph fully therefore you need to have read models that are consistent for particular domain entity version, that is they need to be generated in same transaction;
- Some domain entities have properties that change frequently but need to be included in every read model.
Based on this I am thinking of having query services should:
- For read models that need to be generated frequently and/or are simple projections of domain entities: do not store them but produce them via ORM by querying domain model entities in database;
- For read models that don’t need to be generated frequently and are complicated domain entity projections generate them and store in database tables.
Also I see some people suggest storing read models as blobs. The problem with storing read models as blobs is that in case you will need to search on them you will need to extract properties for indexing and if you need full text search even you have to store them in a format that can be understood by full text tools.
As you can see, I will basically want to have read model that exists after query execution only and is not generated based on domain change events. Is this solution acceptable for CQRS? The reason I am looking into CQRS is to improve application architecture by separating cacheable view models from user action handling, have AJAX enabled web applications with asynchronous updates after user actions, and reduce the room for junior developers to produce unmaintainable code by placing business logic all over the place and even non-faithful implementation of CQRS to me seems like good step into right direction.
CQRS does not require that the read model is stored in separate tables (or documents if you use a document database), although this often is a good approach and works well in combination with event sourcing. A read model can be backed by a database view or ORM query for instance.
This might be a good approach when introducing CQRS to parts of a legacy system.
The approach you’re suggesting here has been suggested before, for instance see this post by Ayende; I think it’s called “thin read model” or similar. I’d say go for it.
You might be interested in reading