Как репозитории сочетаются с CQRS?

Согласно Фаулеру (здесь ), репозиторий «посредничает между слоями отображения домена и данных, действуя как объект домена в памяти. коллекция.Так, например, в моем приложении Courier Service, когда отправляется новый запуск, моя служба приложения создает новый совокупный корневой объект Run, заполняет его значениями из запроса, а затем добавляет его в RunRepository перед вызовом единицы работы для сохранить изменения в базе данных. Когда пользователь хочет просмотреть список текущих запусков, я запрашиваю тот же репозиторий и возвращаю денормализованный DTO, представляющий информацию.

Однако при просмотре CQRS запрос не попадет в тот же самый Вместо этого он, возможно, пойдет прямо против хранилища данных и всегда будет денормализован. И моя командная часть эволюционирует в NewRunCommand и Handler, которые будут создавать и заполнять объект домена NewRun, а затем сохранять информацию в хранилище данных.

Итак, первый вопрос: как репозитории вписываются в модель CQRS, если мы не поддерживаем в памяти коллекцию (кэш, если хотите) объектов домена?

Рассмотрим случай, когда информация, отправленная моему Служба plication не содержит ничего, кроме набора значений ID, которые служба должна разрешить, чтобы создать объект предметной области. Например, запрос содержит ID # курьера, назначенного на рейс. Служба должна искать фактический объект Courier на основе значения идентификатора и назначать объект NewRun с помощью метода AssignCourier (который проверяет курьера и выполняет другую бизнес-логику).

Другой вопрос заключается в том, что с учетом разделения запросов и возможного отсутствия репозиториев, как служба приложений выполняет поиск объекта домена Courier?

ОБНОВЛЕНИЕ

Основываясь на дополнительном чтении и размышлениях после комментария Денниса, я перефразирую свои вопросы.

Мне кажется, что CQRS поощряет использование репозиториев, которые являются всего лишь прикрытием механизмов доступа к данным и их хранения. Они дают «внешний вид» коллекции (как описывает Фаулер), но не управляют объектами в памяти (как указал Деннис). Это означает, что каждая операция над репозиторием является сквозной, да?

Как единица работы вписывается в этот подход? Обычно UoW используется для фиксации изменений, внесенных в репозиторий (правильно?), но если репозиторий не поддерживает объекты в памяти, то какую роль играет UoW?

Что касается операции «записи», будет ли обработчик команды ссылаться на тот же репозиторий, другой репозиторий или, возможно, на UoW вместо репозитория?