search

devas123 / competitionservice

competitionservice
2 stars 0 forks source link

Simplify Competition Service architecture #73

Open devas123 opened 3 years ago

devas123 commented 3 years ago
  1. разделить понятия Event Driven и Event Sourcing (Сервис должен хранить все Event'ы, которые меняют State, служебные event'ы должны храниться отдельно)
  2. Убрать саги внутри сервиса
  3. Сделать адекватный механизм отслеживания последнего State
devas123 commented 3 years ago
  1. последний State всегда хранится в rocksDB. Обработчик Event'ов - это функция Event -> Maybe<State> -> State.
    Мы берем Event, State, и получаем новый State, сохраняем Event'ы и сохраняем новый State - это одна транзакция. в случае если мы свалились с сохранением нового State, мы просто перезапускаем сервис и пересоздаем его из event'ов. Каждый Event переводит State в валидный State (важно!) Таким образом, последний State создается на основе event'ов из kafka один раз, перед тем, как мы обрабатываем первую команду. Дальше берется State из репозитория.
devas123 commented 3 years ago
  1. Просмотреть команды и ивенты, которые сейчас используются.
  2. Логика обработки команд не должна знать о логике кластеризации. Эти аспекты должны быть полностью ортогональными.
  3. Обновление CompetitionState сериализуются для одних соревнований. (может реализовать через Ref[Map[String, CompetitionProcessor]]? тогда можно ему отдать менеджмент базы данных тоже.)
devas123 commented 3 years ago

Promise!

devas123 commented 3 years ago

Естественным образом эта модель вписывается в Actor Model. Обработке каждого CompetitionState соответствует один Actor, при старте он восстанавливает State из Event'ов. Ему передается только EventProvider (в Production это Consumer, в тестах может быть List)

devas123 commented 3 years ago

Event'ы не должны быть императивными. Они не должны быть привязаны к имплементации в compservice.