Убедитесь, что эта идея ясна: может быть более одной «модели чтения» на «модель записи».
Логически, то, что происходит, не сильно отличается от случая «не CQRS»;мы берем информацию, записанную моделью записи, преобразуем ее в интересное представление и возвращаем ее клиенту (в вашем примере, виджету).
Но это не обязательно делать"жить";мы можем ответить на запрос, вернув кэшированную копию представления.
Если вы, например, рассматриваете ресурсы в Интернете - HTTP встроил в него глубокое понимание кэширования.Когда на запрос HTTP поступает ответ из кеша, это в основном чисто обработка представления запроса, нет?
Таким образом, если вы обрабатываете запрос, возвращая представление из кэша, то обработчик собираетсябыть довольно поверхностным.
Вам по-прежнему понадобится код где-нибудь, который берет представление «Книга правды» модели write и преобразует его в представление, подходящее для кэша.Но выполнение этого кода не обязательно должно быть синхронным с запросом - есть сделки свежести и задержки, которые вы можете совершать.
Так что давайте посмотрим, смогу ли яправильно понимаете, модель чтения принадлежит представлению, а обработчик запросов принадлежит прикладному уровню?Не могли бы вы сказать, что следующее имеет смысл?
https://imgur.com/9ndFL3h
Это ... Это совсем не плохо.
Или, что более важнони одна из функций обработчика запросов в моем вопросе не верна.Правильный вызов функции будет что-то похожее на дескриптор (<запрос типа QueryForReadModelABC>).Таким образом, это на самом деле запрос модели чтения, а не запрос конкретного ресурса / объекта, такого как Project или User?
Да.