События, запускающие другие события - саги / менеджеры процессов практически в Акке
Я создаю CQRS-ориентированную систему, использующую постоянство Akka как побочный проект и учебное упражнение. Я ищу помощь в том, как я это моделирую.
Короче, у меня есть игра. Чистая игровая механика - это FSM (я на самом деле использую PersistentFSM для моделирования этого), и я прочитал представления об этом постоянном действующем субъекте, которые клиентский интерфейс API запрашивает, чтобы определить, что визуализировать на стороне клиента. Это работает хорошо.
Игра основана на словах. Короче говоря, вы можете представить, что каждый игрок в игре отправляет несколько предложений, тогда для этих предложений определяется оценка. В зависимости от счета выдается количество монет (игровая валюта).
Итак, есть команды, которые клиент может отправить в игру. Клиент может представить предложение слов. Прямо сейчас я реализую это как обработчики клиентских запросов (я не знаю, с чем они могут быть связаны в мире CQRS, короткоживущей саге /PM?), Получая субъект для обработчика резервных команд FSM и отправляя, например, команды.SubmitSentence (...). Этот обработчик команды затем обрабатывает команду, проверяет предложение и генерирует некоторые события (SentenceSubmitted, как очевидное). Я не совсем уверен, должен ли я отправлять команды непосредственно в PersistentFSM с моего уровня API, поэтому входные данные также приветствуются.
Мой главный вопрос основан на том, как справиться с этим периферийным воздействием. Например, как только каждый игрок отправил предложения, нам нужно генерировать очки и монеты. Очки используются только в представлении для этой игры, но монеты должны быть сохранены в другом месте в системе на тот случай, если игрок захочет их потратить. Я смотрел на это так:
- Игра рассчитывает количество очков и количество монет на основе предложений / других игровых факторов. Это генерирует событие "GameScoreCalculated"
- некоторый "слушатель", например, "CoinListener", подписан на это событие вычисления (если слушатель является одноэлементным, с точки зрения Akka Persistence это событие имеет некоторый тег, на который оно подписано). Я чувствую, что из всего, что я прочитал, это тип ProcessManager. Мне немного непонятно с точки зрения реализации Akka, является ли это "один на игрока" или "один синглтон", или "в каком-то смысле".
- CoinListener, убедившись, что он не получил несколько событий для одной и той же игры, генерирует несколько команд для создания реальных монет (CreateCoin(playerId,...)) и запускает их на себя
- CoinListener реагирует на эти CreateCoins, чтобы сохранить некоторые события CoinCreated
Позже, когда я построю и профиль, и системы закупок, эти области приложения будут использовать события CoinCreated, чтобы собрать, сколько монет на самом деле имеет игрок.
Имеет ли это смысл?
Спасибо Рик