На последнем тренинге поднимался вопрос - стоит ли на модели процесса операционного уровня отображать технические операции (сохранение данных, изменение статуса бизнес-сущности) в виде сервисных задач? Или не указывать явно, используя вместо сервисных задач execution/task listeners?
Пришли к следующим выводам:
"За" отображение:
Явная демонстрация алгоритма и бизнес-логики (не скрыты, а демонстрируются на диаграмма)
Больше гибкости (проще поменять место расположения элемента диаграммы, чем перепрописать listener)
Возможность использования wait states, разделения/объединения транзакций
Явное выделение / обработка ошибки
"Против"
Модель процесса становится “перегруженной”, сложной
Думаю, что “ЗА”.
А чтобы модель процесса не становилась “перегруженной” и сложной,
нужно руководствоваться лучшими практиками по моделированию от Camunda.
Есть 2 уровня модели бизнес-процесса: технический и стратегический.
Стратегический подойдет для тех, кому не обязательно быть в курсе всех технических особенностей, и видеть весь процесс в целом, с точки зрения бизнеса. Подойдет для руководства, менеджеров.
Поддерживаю подход за выделение отдельных сервисных задач.
Описанные аргументы “ЗА”, перевешивают “Против”. По схеме важно понимать как процесс работает (а в листернах это еще нужно раскапывать), также такой подход ускоряет процесс поиска, отладки и исправления ошибок, что также немаловажно.
Кроме того, исполняемая модель процесса так или иначе заполняется техническими операциями и этого вряд ли удаться не избежать.