Эта статья посвящена запросам и CQRS, чтобы создать основу для реализации стратегии кэширования.
В одной из своих предыдущих статей я писал, что если бы мы могли реализовать модель связи между издателем и подписчиком и издатели могли бы упаковать всю необходимую информацию в события об изменении состояния, то у подписчиков были бы все данные для работы, и запросы можно было бы избежать. В то время как модель pub-sub обычно приводит к созданию масштабируемой системы с высокой пропускной способностью за счет устранения сложностей из приложения и переноса их в инфраструктуру, мы не можем использовать модель pub-sub во всех случаях.
Системам действительно необходимо делать запросы на чтение или поиск, потому что они либо лучше моделируют вариант использования, либо из-за своей простоты. Такой запрос на получение данных называется запросом.
Как помогает разделение путей чтения и записи?
Любое программное обеспечение, имеющее дело с хранилищем данных, может либо сохранить один и тот же путь для обновления и чтения данных, что является общим для операций доступа к данным в стиле CRUD, либо может отделить операцию обновления данных от операции чтения данных. Это простое разделение известно как шаблон разделения ответственности командных запросов (CQRS). Команды отвечают за изменение состояния, а запросы — за чтение состояния.
Для академических интересов вот несколько статей из 2010 и 2012 Грегори Янга (который ввел термин CQRS), где он объясняет CQRS только как разделение проблем с целью чтение и запись путем создания 2 отдельных объектов. И проясняет мифы, окружающие CQRS, которые часто делают его более сложным, чем предполагалось.
Шаблон прост и понятен, но он открывает образ мышления, связанный с различным восприятием и асимметричными потребностями при запросе или обновлении данных. И по мере того, как этот образ мышления применяется к разным контекстам, он начинает принимать разные формы. .
Например, в контексте доменно-ориентированного дизайна, возможно, кластер объектов домена образует агрегат и должен обновляться вместе, чтобы поддерживать целостность агрегата, хотя при чтении может потребоваться просто извлеките один или несколько объектов предметной области из хранилища данных.
Или в контексте реляционной базы данных, где путь чтения может использовать представление, построенное поверх таблиц данных.
Или когда хранилище данных для чтения представляет собой отдельный физический узел, либо для хранилища данных с эффективным чтением, сокрытия информации или для требований асимметричного масштабирования чтения (или это может быть простая реплика чтения).
Или другой возможностью может быть то, что хранилище данных запроса строится на событиях, а не на основном хранилище данных. Как в этом примере Уди Дахана —
- Отправляется команда для обновления состояния.
- Состояние обновляется в базе данных и событие публикуется.
- Хранилище запросов, которое в этом примере является кешем, обновляется.
В зависимости от того, как разработана модель чтения, будь то доступ к данным на основе CRUD или раздвоенный CQRS, можно применить одну из нескольких стратегий кэширования. В следующей статье я напишу о кэшировании.
Ссылка на Следующую часть
Кредиты https://learn.microsoft.com/en-us/azure/architecture/patterns/cqrs
