Pull to refresh

Comments 15

Описанное — наглядная демонстрация, какие проблемы создает использование визуальное представление логики. Оно, может, и удобно (но ради где-то 20 логических элементов целый лист занимать?), но требует вот таких специализированных инструментов. И что происходит, когда нужно слить ветки и вот в таком файле получается конфликт?

В ваших аргументах против BPMN есть зерно истины. Но визуальное представление логики — это далеко не всё (и не главное), ради чего BPMN используется. Есть ещё несколько аргументов за. Например, прозрачная обработка ошибок и политика попыток повторного исполнения (организовать то же самое только в коде значительно сложнее). Бизнесс-процессы могут иметь довольно сложную и разветвлённую структуру. Это все можно организовать на уровне кода, но поддерживать становится довольно затратно. Ещё организация таких штук, как SAGA.
А по поводу конфликтов золотой пули нет. Большинство таких проблем можно решить организационно: над одним бизнесс-процессом не могут работать параллельно несколько человек.

Это все можно организовать на уровне кода, но поддерживать становится довольно затратно.


Почему? Имеется в виду, разумеется, что надо использовать не язык общего назначения, а текстовый язык описания всех этих бизнес-процессов. Таких нет?

Имеется в виду, разумеется, что надо использовать не язык общего назначения, а текстовый язык описания всех этих бизнес-процессов.

Вы вот сейчас BPMN описали. Серьёзно.

Не графические языки. Вот эти 17-20 узлов, что на картинке есть — их ну пусть в 30 строк на экране — никак выразить нельзя? Пользователи и разработчики этих схем способны выучить графическую нотацию но не способны — текстовую?


А саму диаграмму, если это кому-то улучшает понимание, можно по этому тексту дополнительно нарисовать в соседнем окне.

Мне такие не известны. В такой схеме непонятно как обеспечить соответствие описания и графического представления.

В смысле, как? Графическое представление генерируется на ходу из текста. Т.е. текст — первичен, а картинка — иллюстрация для облегчения понимания.


Ну вот если диаграмму в plantuml рисовать в IDE — рядом можно открыть окошко, где эта диаграмма и будет нарисована. Но если картинки нет, а у меня текстовый diff изменения показывает — я все равно смогу понять, что тут узел вставили.

Видимо, имеются в виду языки типа Gherkin. И даже есть тулзы, генерящие модели по feature-файлам (не уверен, правда, что в BPMN).
Но у автора статьи визуальное моделирование — часть процесса автоматизации, а схемы BPMN получаются как артефакты этого моделирования, поэтому их нельзя заменить на что-то.

Все верно: схемы BPMN — артефакты, которые можно распространять между членами команды с разными ролями и между командами.

Хорошо бы сделать последнюю картинку кликабельной.
Честно говоря, понятия не имею как тут это сделать. Оригинальная картинка имеет довольно большое разрешение, поэтому её можно открыть в новой вкладке и там будет все хорошо видно.
Красиво, но:
1. визуальное отображение может пропустить детали изменений в BPMN (к примеру, добавили условие в decision table)
2. вместо решения проблемы с diff-viewer для xml (очевидно, он лажает), вы создали проблему поддержки нового решения.

Резюме: спорная выгода.
  1. Про поддержку DMN я ничего не говорил. Но можно и DMN поддержать. Вообще, я упоминал в статье, что в основе лежат библиотеки от создателей Camunda (см. https://bpmn.io/). Эти библиотеки отвечают за отрисовку и за вычисление diff двух моделей. Я уверен, что подавляющее большинство кейсов они покрывают. Практика покажет насколько точно они это делают. Но ручное сравнение уже показало свою несостоятельность.
  2. Тут вопрос цены. Допустим в компании 100 человек задействованы в разработке бизнесс-процессов. Что дешевле: одному человеку поддерживать плагин (скорее всего очень редко что-то придется реально делать) или сотне людей ежедневно проходить через боль ручного сравнения и риски связанных с этим ошибок?
Согласен — решение ситуативно.
В моем случае выгода показалась спорной из-за пунктов выше. В вашем случае, уверен, были причины за создание решения.
Спасибо что поделились.
Очень интересная идея. Сам сталкивался с ручным мержем процессов. К сожалению, используем в работе gitlab.
Sign up to leave a comment.