Отображение технических операций на диаграмме процесса: "За" и "Против"

Дорогие коллеги!

На последнем тренинге поднимался вопрос - стоит ли на модели процесса операционного уровня отображать технические операции (сохранение данных, изменение статуса бизнес-сущности) в виде сервисных задач? Или не указывать явно, используя вместо сервисных задач execution/task listeners?

Пришли к следующим выводам:

"За" отображение:

  • Явная демонстрация алгоритма и бизнес-логики (не скрыты, а демонстрируются на диаграмма)
  • Больше гибкости (проще поменять место расположения элемента диаграммы, чем перепрописать listener)
  • Возможность использования wait states, разделения/объединения транзакций
  • Явное выделение / обработка ошибки

"Против"

  • Модель процесса становится “перегруженной”, сложной

А как думаете Вы?

Думаю, что “ЗА”.
А чтобы модель процесса не становилась “перегруженной” и сложной,
нужно руководствоваться лучшими практиками по моделированию от Camunda.
Есть 2 уровня модели бизнес-процесса: технический и стратегический.
Стратегический подойдет для тех, кому не обязательно быть в курсе всех технических особенностей, и видеть весь процесс в целом, с точки зрения бизнеса. Подойдет для руководства, менеджеров.

1 симпатия

Поддерживаю подход за выделение отдельных сервисных задач.
Описанные аргументы “ЗА”, перевешивают “Против”. По схеме важно понимать как процесс работает (а в листернах это еще нужно раскапывать), также такой подход ускоряет процесс поиска, отладки и исправления ошибок, что также немаловажно.
Кроме того, исполняемая модель процесса так или иначе заполняется техническими операциями и этого вряд ли удаться не избежать.