Справочная информация
Мы разрабатывали микросервис для управления бронированиями в нашей системе.Поэтому мы решили решить эту проблему с помощью абстракции конечного автомата, т.е. бронирования могут находиться в одном из нескольких состояний и могут быть переведены в другое посредством некоторых действий / событий.
У нас были очень полезные дискуссии между мной и моиммы с коллегой придерживались иного мнения о том, как должен создаваться государственный аппарат.Я взял пример REDUX , где у нас разные ДЕЙСТВИЯ (СОБЫТИЯ + ЗАГРУЗКА) и на основе ACTION.TYPE мы переводим нашу систему на другую СОСТОЯНИЕ .
Это было довольно просто, но мой друг ввел в заблуждение такой фактор, как ДЕЙСТВИЯ и СОБЫТИЯ : две совершенно разные вещи (которые, по моему мнению, должны быть одинаковыми в любом автомате)) И он утверждает, что СОБЫТИЯ заставляют некоторые ДЕЙСТВИЯ выполнять на конечном автомате для перехода к другому STATE .И его смысл: СОБЫТИЯ & ДЕЙСТВИЯ - это два совершенно разных аспекта, и они не должны быть одинаковыми.Они имеют разные точки и значения.
Например, для некоторых СОБЫТИЕ может быть CREATE_REQUEST , но на самом деле поиск доступности и бронирование - это АКЦИЯ получено CREATE_REQUEST событием.
Но я полностью не согласен и я решительно говорю, что ACTION должно быть чем-то вроде [CREATE_REQUEST, {DATES, ...OTHER_INFO}] и машина должна работать соответствующим образом и перейти к некоторому другому STATE .
, так что подход должен быть правильным.
├── src
| ├── ACTIONS
| ├────── CREATE_REQUEST // return {TYPE: CREATE_REQUEST, {data}}
| ├────── DECLINE_REQUEST //return {TYPE: DECLINE_REQUEST, {id}}
| ├── STATES
| ├────── DRAFT
| ├────── PENDING
| ├────── REQUESTED
| ├────── COMPLETE
Я жду некоторых советов экспертов и советов, чтобы у нас было четкое представление о том, что делать.