Краткий ответ: да, вы можете.
CQRS как архитектурный стиль появился после DDD.Он основан на Разделение команд-запросов (CQS) .
В качестве шаблона CQRS может использоваться для оптимизации вашего приложения.Если вам нужно показать много данных пользователю из нескольких агрегатов одновременно, вам может потребоваться выполнить много запросов к базе данных, чтобы получить эти данные.Это может стать неэффективным.Вот некоторые варианты, которые вы можете выбрать (конечно, не полный список):
Опция 1 : компромисс для вас Модель домена для удовлетворения этого требованиянужно и сделать его более подходящим для чтения.
Вариант 2: Полностью разделите два, как это делает CQRS.Сохраняйте хорошую модель записи, которая представляет ваш домен, и в то же время используйте модель чтения, которая показывает, как вы хотите, чтобы ваши данные отображались пользователю.
Опция3 Создайте свой пользовательский интерфейс / интерфейс, чтобы не показывать все данные одновременно.Например, возьмем способ, которым пользовательский интерфейс в телефонах работает.Так как они имеют меньшие экраны, более медленный процессор и меньше оперативной памяти, а самое главное: батарея, которая постоянно разряжается, они обычно показывают небольшую часть данных, а затем вам нужно переходить, чтобы увидеть больше.Делайте один запрос за другим вместо огромного и покажите все на одном экране.Вы можете противопоставить это настольным приложениям, которые имеют богатые меню, и при их открытии показывают множество вещей.
Это создает дополнительную сложность, которой вы, возможно, не захотите управлять, поэтому выможет выбрать вариант 1 или 3 в зависимости от вашей организации (заставить людей проектировать пользовательский интерфейс таким способом может быть сложно, поэтому вы можете пойти на вариант 1 в качестве компромисса).
По моему опыту, если вы не разрабатываете приложение, которое будет обрабатывать данные от большого количества пользователей (скажем, 200 000, и даже тогда это может быть хорошо), вы можете пропустить CQRS.Если у вас возникла эта проблема позже, вы всегда можете изменить ее.Наличие единственной симпатичной доменной модели облегчает последующее внедрение CQRS.
Если вы не читали книгу DDD , я настоятельно рекомендую ее.
Вот отличная статья для CQRS .В нем обсуждается, как большинство людей считают, что вы должны использовать отдельные базы данных, чтобы сделать распространение от записи к чтению асинхронным.
Вполне нормально иметь одну базу данных для двух моделей и сделать распространение синхронным.Вы даже можете сделать обновления модели чтения в той же транзакции, если используете транзакционную базу данных, чтобы избежать возможной согласованности.Это уменьшит сложность, но может привести к дополнительным задержкам, если ваша сторона записи также сильно загружена.Если это так, вы можете использовать асинхронное и в конечном итоге непротиворечивое решение и разобраться с его последствиями.
Примените некоторый начальный анализ и посмотрите, принесет ли CQRS какое-либо значение.Если это действительно начинается с этого.Если этого не произойдет, начните без него.Если вы новичок в DDD и CQRS, лучше не начинать с обоих в одном приложении, так как вы можете столкнуться с неожиданной сложностью и оказаться в сложной ситуации.Начните с DDD, приобретите в нем опыт, а затем вы можете попробовать CQRS.