Комментарии 15
Описанное — наглядная демонстрация, какие проблемы создает использование визуальное представление логики. Оно, может, и удобно (но ради где-то 20 логических элементов целый лист занимать?), но требует вот таких специализированных инструментов. И что происходит, когда нужно слить ветки и вот в таком файле получается конфликт?
В ваших аргументах против BPMN есть зерно истины. Но визуальное представление логики — это далеко не всё (и не главное), ради чего BPMN используется. Есть ещё несколько аргументов за. Например, прозрачная обработка ошибок и политика попыток повторного исполнения (организовать то же самое только в коде значительно сложнее). Бизнесс-процессы могут иметь довольно сложную и разветвлённую структуру. Это все можно организовать на уровне кода, но поддерживать становится довольно затратно. Ещё организация таких штук, как SAGA.
А по поводу конфликтов золотой пули нет. Большинство таких проблем можно решить организационно: над одним бизнесс-процессом не могут работать параллельно несколько человек.
Это все можно организовать на уровне кода, но поддерживать становится довольно затратно.
Почему? Имеется в виду, разумеется, что надо использовать не язык общего назначения, а текстовый язык описания всех этих бизнес-процессов. Таких нет?
Имеется в виду, разумеется, что надо использовать не язык общего назначения, а текстовый язык описания всех этих бизнес-процессов.
Вы вот сейчас BPMN описали. Серьёзно.
Не графические языки. Вот эти 17-20 узлов, что на картинке есть — их ну пусть в 30 строк на экране — никак выразить нельзя? Пользователи и разработчики этих схем способны выучить графическую нотацию но не способны — текстовую?
А саму диаграмму, если это кому-то улучшает понимание, можно по этому тексту дополнительно нарисовать в соседнем окне.
Мне такие не известны. В такой схеме непонятно как обеспечить соответствие описания и графического представления.
В смысле, как? Графическое представление генерируется на ходу из текста. Т.е. текст — первичен, а картинка — иллюстрация для облегчения понимания.
Ну вот если диаграмму в plantuml рисовать в IDE — рядом можно открыть окошко, где эта диаграмма и будет нарисована. Но если картинки нет, а у меня текстовый diff изменения показывает — я все равно смогу понять, что тут узел вставили.
Но у автора статьи визуальное моделирование — часть процесса автоматизации, а схемы BPMN получаются как артефакты этого моделирования, поэтому их нельзя заменить на что-то.
1. визуальное отображение может пропустить детали изменений в BPMN (к примеру, добавили условие в decision table)
2. вместо решения проблемы с diff-viewer для xml (очевидно, он лажает), вы создали проблему поддержки нового решения.
Резюме: спорная выгода.
- Про поддержку DMN я ничего не говорил. Но можно и DMN поддержать. Вообще, я упоминал в статье, что в основе лежат библиотеки от создателей Camunda (см. https://bpmn.io/). Эти библиотеки отвечают за отрисовку и за вычисление diff двух моделей. Я уверен, что подавляющее большинство кейсов они покрывают. Практика покажет насколько точно они это делают. Но ручное сравнение уже показало свою несостоятельность.
- Тут вопрос цены. Допустим в компании 100 человек задействованы в разработке бизнесс-процессов. Что дешевле: одному человеку поддерживать плагин (скорее всего очень редко что-то придется реально делать) или сотне людей ежедневно проходить через боль ручного сравнения и риски связанных с этим ошибок?
Как я подружил BPMN и Bitbucket