Finite State Machines (FSM) Конечные автоматы
workflow engine vs state machine
Зачем
Необходима гибкая модель настройки состояний, условий и возможных переходов на уровне ИС.
- множество состояний объекта
- множество допустимых переходов по бизнес правилам
- множество доступных операций для каждого состояния, в контексте каждой Роли
- триггеры событий перехода из состояния
- обработчик события “До перехода”, “После перехода”
Кейсы по использованию Статусной модели (модели FSM):
- Определить декларативно множество состояний объекта: A, B, C, D, E , F, среди который одно - Начальное, и, как минимум, одно Конечное.
- Определить декларативно множество допустимых переходов: A-B, B-C, C-D, D-A, D-E
- Определить декларативно множество доступных операций для каждого состояния, в контексте каждой Роли.
- Например: для статуса “На согласовании” - для роли “Автор заявки” доступны операции Просмотр, Отзыв; - для роли “Согласовант” - “Просмотр”, “Согласовать”, “Отклонить”
- Определить декларативно для каждого перехода Х ->Y, обработчик события “До перехода”, “После перехода”
- Множество операций, доступных в качестве обработчика этих событий, определены в коде приложения, но доступны для выбора пользователю по своему идентификатор, т.е. для декларативного определения.
- Например, для перехода “На согласовании” -> “Согласовано” перед переходом отрабатывает валидатор-бизнес правило, проверяющее сумму заявки, в качестве пост-обработчика для этого перехода можно декларативно объявить метод “Отправить уведомление” с параметрами, значения которых будут подставлены из атрибутов Заявки (Email с уведомлением получит Автор заявки)