Comments 10
А теперь задание со звездочкой - быстро и на кончиках пальцев понять в каком месте bpmn используется произвольный кусок кода? И в обратную сторону - какой конкретно код лежит под каждым кубиком диаграммы? Пока двусторонний переход из bpmn в код и обратно нельзя будет сделать по привычному ctrl+клик использование камунды в продакшене будет мучением для развития и поддержки.
У нас в проде на одном из проектов уже есть решение где BPMN вызывает функцию описанную в JAVA. Уверен что потратив немного сил на поиски вы найдете решение, я же обозначил возможность и плюсы.
вызывает функцию описанную в JAVA
Всего одну? Вы понимаете, что по сути каждый элемент bpmn будет ссылаться на "какой-то код" - каждый кубик, каждая стрелка будет смотреть в java-код. Не имея быстрого и надежного средства навигации туда-сюда поддержка и развитие превратится в адЪ, где львиная доля времени будет уходить на поиски откуда ноги растут.
А без BPMN? Зная, примерно, что какая-то функциональность должна быть реализована в коде, как ее найти? И по коду, как разобраться за какую часть бизнес процесса этот код отвечает? Ctrl+клик не сложно реализовать, но имхо это повлияет не так сильно, как в целом наличие описанных процессов в BPMN. (Впрочем это не оправдывает пост, который обрывается на середине слившись во что-то странное после спорного аргумента против postgresql)
Ваши представления строятся на достаточно небольших проектах, в которых видимо нет тестовой, дев и прод среды. Не прописаны регламенты вывода в прод, проведение определенных процедур для деплоя. Мысль в первую очередь в том чтобы пройти этот путь, задеплоить сервис и при необходимости быстро менять бизнес процессы (в определенных пределах конечно) и не ждать 1-2 спринта пока изменения появятся на проде. Использование bpmn решает эту задачу т.е. ускоряя time-to-market практически до минут, а не дней и недель.
Если у вас коротки процесс вывода в прод и бизнес логика примитивна (простая), bpmn вам только помешает и не предоставит тех возможностей о которых я говорил.
Насчет PG - все просто попробуйте его нагрузить 100к параллельными запросами и потом я готов обсудить как вы себя чувствуете после этого, как вырос SLA и т.п.
То что я описал релевантно для больших, корпоративных, высоконагруженных проектов.
Не знаю почему этот комментарий адресован сюда. Я работал с системой где на postgresql кластере было легко получить 100к параллельно висящих запросов но не заметить при этом больших проблем на проде.
Новый правленый bpmn точно так же нужно выводить в прод, его точно так же нужно тестировать. На круг сам по себе его наличие ничего не ускоряет.
Давай так - имея только код ориентироваться будет на круг всяко легче, чем имея код И bpmn, который связан с кодом совершенно не очевидным образом. К тому же у нас микросервисный мир, в котором есть такая штука, как api, которое является единой точкой входа в сервис, имея эту точку разматывать клубок становится сильно легче, а для камунды ничего подобного нет - все в не явном виде на текстовых метках, по которым нет толком ни поиска, ни навигации.
Проблема этих систем, которые позволяют "менять логику прямо в проде" в том, что они ужасные в плане дебага, ужасные в плане обработки ошибок, ужасные в плане разработки самих схем. Это все настолько геморно и тяжело, что пользователи тупо перестают пользоватеься этим "счастьем", которое "быстро и удобно", и пишут тикет на разработку компании-разработчику. Проще и быстрее дать деняк.
И разработчики, которых заставили написать "инструмент" "кодлесс" для пользователей, вынуждены САМИ "разрабатывать" процессы в том, что они наваяли. Вместо удобного и привычного кодинга-дебаггинга на Java - в каком-то.... позоре.
Еще хуже, когда звезды-сеньоры-иксперды не желают разрабатывать процессы в тех инструментах, что они наваяли, и сбрасывают эту работу на молодняк или на отделы попроще. Это приводит к деградации и распаду целых отделов (с неслабо оплачиваемыми разработчиками, на минуточку).
Я знаю, и с камундой связывался, и с самописными отчетными системами.
Я вас расстрою, но то понятие, которое вы привели для оркестрации - это не оркестрация. Оркестрация - это когда есть те, кого надо оркестрировать. А у вас понятие алгоритма просто дано.
Не надо называть оркестрацией то, что ей не является.
Оркестрация на BPMN: взгляд изнутри