Добавлю к ответу
Юрий:
Одна из основных вкусняшек Workflow в подобных компонентах/фреймворках/системах - это инверсия контроля над сущностями и прочими моделями. Клиент не изменяет статус сущности через условный сеттер setStatus('approved') с дополнительными сайд-эффектами, а осуществляет переход (действие, процесс) apply('approve'), одним из сайд-эффектов которого является изменение статуса. Вроде бы разница незначительная с технической точки зрения, но бизнес-заказчики обычно оперируют процессами, в которых задействованы сущности, а не операциями самих сущностей, они говорят "в результате подписания договора ему присваивается статус "действующий"", а не "присвоение договору статуса "действующий" означает что договор подписан". Когда их требование меняется на "в результате подписания договора ему присваивается статус "подписан" (которого раньше не было), а "действующий" присваивается когда менеджер его утвердит", то нам, разработчикам, значительно меньше приходится менять и чаще всего не код даже, а конфиги, код только дописывается, но не меняется, ну или меняется значительно в меньшей степени.
