Комментарии 7
Спасибо за полезную статью, не помешало бы больше кода %)
После некоторого опыта работы с bpm движками подобный маркетинг вызывает лишь улыбку. Оно все хорошо на примерах уровня - пара тасков и шлюзов, но в реальной жизни это боль и мучения.
Почему-то всегда в подобных статьях упускают такие моменты:
– Как версионировать БП, как мигрировать со старой версии на новую?
– А если при этом состав процессов или модели данных несовместимы?
– Где хранить актуальное состояние модели: только в инстансе процесса или во внешнем хранилище? Если во внешнем хранилище как решать проблему конкурентного доступа?
– Как вообще рефакторить это все это добро?
– И самое главное: а какой вообще bpm дает профит? По своей сути bpmn - это описание конечного автомата, так почему не использовать, например, акторную модель?
Добрый день. Всё зависит от задачи, условий и уровня владения тем или иным инструментом. В общем случае сеньор-разработчику зачастую проще написать все чистым кодом, тогда как бизнесу бывает удобнее Camunda – чтобы наглядно видеть блок-схему процесса и легко подключать к проекту разработчиков любого уровня, не требуя от них погружения в чужой код.
Что касается вопросов, мы сделали несколько предположений, исходя из опыта нашего проекта – и в других проектах, безусловно, могут быть свои особенности.
1. Как версионировать БП, как мигрировать со старой версии на новую?
Можно указать в пулах version tag, кроме того, при деплое активные процессы закончат свой жизненный цикл по старой версии схемы.
2. А если при этом состав процессов или модели данных несовместимы?
Основы SOLID говорят, что проект должен быть открыт для расширения, но закрыт от изменений. Модель данных нужно менять в рамках разумного.
3. Где хранить актуальное состояние модели: только в инстансе процесса или во внешнем хранилище? Если во внешнем хранилище как решать проблему конкурентного доступа?
Можно хранить в контексте или во внешней БД (что даже лучше). Проблему конкурентного доступа нужно решать по мере ее возникновения, иначе сориентироваться трудно, если вообще возможно. Острее будет стоять вопрос версионирования и миграций БД. Также стоит присмотреться к документоориентированным БД.
4. Как вообще рефакторить это все это добро?
Рефакторить как раз-таки просто: схема оказывается отвязана от кода и можно с большой степенью свободы менять реализацию как схемы, так и кода.
5. И самое главное: а какой вообще bpm дает профит? По своей сути bpmn - это описание конечного автомата, так почему не использовать, например, акторную модель?
Дело в скорости разработки: в чистом коде реализация займет гораздо больше времени, а поддерживать может быть нелегко из-за запутанной паутины вызовов и управления доступом. Хотя, где-то действительно можно и проще работать без bpm – каждый решает сам.
Если модель данных не менялась и бизнес согласен, что старые процессы доживают по старой версии, то все отлично. Но если менялась модель данных или бизнес хочет, чтобы процессы пошли по новому пути, то вас ждут проблемы.
Вы неверно понимаете принцип открытости/закрытости, кроме того он не для модели данных. Модель данных легко может быть изменена. Допустим, изначально в контактах предполагался один номер телефона, а захотели хранить список. Можно конечно завести новое поле, оставив старое. Но такой подход в конечном счете приведет к засорению структур. При обычной разработке в такой ситуации произвели бы миграцию данных. В случае с БПМС и хранением объектов в инстансах БП возникает ошибка десериализации. Хранение во внешнем хранилище конечно спасет от этого, но создаст свои (конкурентный доступ, неконсистентное состояние).
На вопрос вы не ответили, оставив решение прикладному разработчику. И это понятно, т.к. правильного решения тут нет, оба варианта имеют минусы.
Рефакторить это не так просто, особенно, когда БП разрастается на несколько экранов, и когда идет перевызов других БП.
Насчет скорости разработки тут спорно. Рисовать hello world в BPMN безусловно быстрее и красивее. Реальные же процессы рисовать долго, а отлаживать еще дольше.
Вообще я не с потолка взял все эти проблемы. Это был наш горький опыт.
Всем привет! Вышло продолжение статьи - на этот раз рассмотрим особенности тестирования моделей процессов.
Автоматизируем бизнес-процессы с Camunda и Spring Boot: отказоустойчивая реализация BPM-схем