Как я понимаю, CQRS выступает за отделение моделей чтения от моделей предметной области и наличие конкретной модели считывания для каждой необходимой проекции модели предметной области.

С точки зрения использования то, как модель чтения хранится и извлекается, должно быть прозрачным - вы отправляете запрос и получаете модель чтения, не заботясь о том, как она сделана.

Многие примеры и статьи используют отдельные таблицы для хранения моделей чтения и их повторной генерации в ответ на изменения модели предметной области.

Мне не очень нравится этот подход по следующим причинам:

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.

Исходя из этого, я думаю, что службы запросов должны:

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.

Также я вижу, что некоторые люди предлагают хранить прочитанные модели в виде блобов. Проблема с сохранением прочитанных моделей в виде больших двоичных объектов заключается в том, что в случае необходимости поиска по ним вам нужно будет извлечь свойства для индексации, а если вам нужен полнотекстовый поиск, вам даже нужно сохранить их в формате, понятном для полного текста. инструменты.

Как вы можете видеть, я в основном хочу иметь модель чтения, которая существует только после выполнения запроса и не генерируется на основе событий изменения домена. Является ли это решение приемлемым для CQRS? Причина, по которой я изучаю CQRS, заключается в том, чтобы улучшить архитектуру приложений, отделив модели кэшируемых представлений от обработки действий пользователя, веб-приложения с поддержкой AJAX с асинхронными обновлениями после действий пользователя и сократив пространство для начинающих разработчиков для создания неуправляемого кода путем размещения всей бизнес-логики. и даже неверное внедрение CQRS мне кажется хорошим шагом в правильном направлении.