Комментарии 9
По какой-то причине есть люди, считающие что BPMN это zero code. Нарисовал, сохранил XML и оно заработало. Но в реальности разработчику приходится иметь дело и с бизнес процессом, куда он погружаться не хочет, и с кодом одновременно.
Ну да, матчасть (нотацию) надо учить.
Как и любой другой инструмент.
А то бывает разработчики такого лепят на BPMN, что кровь из глаз.
Да, это не интуитивно понятно - вроде квадратики-стрелочки, ан нет.
но кому сейчас легко?
Ваш комментарий перечеркнул посыл статьи. :)
Есть два типа стейкхолдеров. Продуктовые знают Что, но не знают Как. Инженерные знают Как но не знают Что. Ни первые ни вторые не любят погружаться в домены друг друга. Отсюда вывод - инструменты, требующие оба сразу - не удобные и не простые, как их пытаются представить. Красивая игрушка для руководства в энтерпрайз, где могут себе позволить. В конторах попроще встречал лишь как слайды презентаций заказчикам. Поправьте, если что.
В точку. Поэтому необходимо сделать так, чтобы продуктовые ничего не писали на каких либо языках, а оперировали лишь бизнес смыслом и переменными, а разработчики реализовывали на своём языке сервис таски как юнит тесты. Иначе будет как вы написали. Нам эту модель до конца ещё не удалось воплотить, пока ещё разработчики дебажат bpmn, но если контракт для ServiceTask/UserTask полностью декларировать в камунде, то тогда открывается возможность разработчику вообще не открывать камунду. Правда тогда именно продуктовики будут дебажить, но они уже это делают. Вам спасибо, за меткое разделение стейкхолдеров.
Да не за что. Если получится, то ждём статью. Противоречие не решаемо десятилетиями. Не зря Камунде придумали альтернативны code first. Клиенту нарисуем за его деньги любые нужные ему картинки, а работать будем как нужно нам.
У себя в LowCode платформе мы вначале делаем контекст домена, рисуем модель, а только потом на этих понятиях делаем BPMN для заказчика первую версию, но именно "за его деньги любые нужные ему картинки" а потом определенным образом превращаем в ServiceTaskи по клику и несколько итераций по приведению bpmn в реальный вид. В одной из своих прошлых LowCode платформ был даже свой движок BPMN, который не по нотации, но ближе к делу, так как контекст был не из дурацких переменных камунды, а нормальной ООП модели домена, это гораздо интереснее, но есть серьезный минус.
Да, проблема существует.
Но правда в том, что ни аналитики, ни разработчики толком не знают нотацию.
Правда, не знают ее по-разному.
Однако, есть пересечение, пусть и небольшое.
Окей, будем просвещать. Gutta cavat lapidem. Вроде так говорили.
Люди, которые придумывали нотацию, верили, что это будет общий язык технарей и бизнеса. Пока не случилось. Некоторые вещи доходят медленно.
Из моей практики -- если человеку объяснять, обычно он понимает.
Вот, например, такая классная вещь, как компенсации.
Вообще никто не шарит, ни айтишники, ни бизнес.
Сколько ж я раз ее уже выпиливал из проектов где она как 5 нога для собаки (скорее как яхта в болоте на даче). В проектах не уровня тяжелого энтерпрайза, где есть люди хорошо в нее умеющие (включая аналистов умеющих в bpmn), профит который она дает не стоит колоссальных инвестиций времени разработчиков в ее базовое понимание, так же как и существенного роста стоимости поддержи (привет распределенные транзакции и бэкапы баз, которые нельзя снять одномоментно). Обычная стейт машина в базе решает 95% быстрее и лучше (хотя и требует кода и настроек).
Спасибо за подсказку, что есть (Pull-принцип) , не знал этого.
Используйте Camunda как удобный REST-движок для оркестрации и workflow — без необходимости работать с Java