Какую проблему решает библиотека
Workflow (с англ. "Бизнес процесс", далее БП) - в контексте разработки, как правило, под этим понимают описание бизнес процесса. В данном случае под БП понимается описание возможных состояний сущности и переходов этой сущности из одного состояния в другое.
Для примера рассмотрим описание упрощённого процесса создания документации.
В данном случае мы видим в каких состояниях может находиться наша сущность "Документация". Как правило, этого не достаточно для того, чтобы можно было отдать в разработку данный процесс: очевидно, что из данной схемы не понятно как называются переходы (скорее всего, так и будут называться кнопки в UI), не ясно что за сущность.
Дополняем недостающую информацию:
Как видно, состояния переименованы, чтобы больше соответствовать происходящему. Далее, нам надо определить какими атрибутами обладает наша сущность.
Теперь, когда есть понимание, какими атрибутами обладает сущность, надо бы описать сами переходы - возможно, есть какие-то ограничения?
Отлично, теперь по схеме можно будет также понять, какие правила валидации надо применить перед сохранением новой статьи. Возможно, после сохранения надо что-то сделать?
В схеме мы забыли опубликовать нашу статью.
Отлично, теперь у нас есть понимание всего процесса и мы, наконец, подходим к проблеме:
Как программно описать схему бизнес процесса, чтобы иметь возможность динамически менять эту схему, без задействования разработчиков?
Ответом именно на этот вопрос и является текущая библиотека.