Структура модуля доступа к данным¶
Обработчики событий и модуль API запросов не обращаются к хранилищу данных напрямую. Вместо этого задействуется специальный модуль, который состоит из объекта доступа к данным (Data Access Object, DAO) и его вспомогательных классов.
Поддержка конкурентности¶
Если события, на которые подписано представление, публикуются агрегатами одного типа, никаких проблем с конкурентностиью не возникает — события обрабатываются последовательно. Однако, если события публикуются агрегатами разных типов, существует вероятность того, что несколько обработчиков одновременно попытаются обновить запись.
И DAO должен корректно обрабатывать подобные ситуации. Если для реализации обновления DAO считывает, и затем записывает обновленную запись, нужно использовать пессимистичное или оптимистичное блокирование.
Идемпотентные обработчики событий¶
Одно событие может быть доставлено более одного раза. Если обработчик на стороне представления идемпотентный - это не проблема (помимо временной рассинхронизации хранилища данных представления). Если же обработчик неидемпотентный, необходимо отклонять повторяющиеся сообщения (см. шаблон “идемпотентный потребитель”).
Клиентские приложения могут использовать представления с отложенной согласованностью¶
В случае, когда клиент обновляет командную сторону, и затем немедленно отправляет запрос, он может не увидеть собственное обновление.
Можно применить следующий подход. Операция командной стороны возвращает клиенту токен с ID опубликованного события. Клиент указывает этот токен в операции запроса. Если обновление еще не прошло, вернется ошибка. Этот механизм можно реализовать, используя систему повторящихся событий.
Дата создания : 29 июля 2022 г.