А что вы понимаете под 'модель данных'?

Бизнес сущности, которыми оперирует процесс

Процессы общающиеся через поток сообщений более «стандартный» подход по BPMN вроде. Кроме того, с подпроцессами есть один минус. Обновление верхнеуровневого процесса затрагивает все сущности, которые отрабатывают в подпроцессах. А если надо мигрировать то масштаб больше чем обновление в схеме с сообщениями

Нормальный вариант 2-3 камунды например. Отталкивайтесь от ролевой модели. Один бизнес-одна камунда. Просто в камунде есть подмена понятий. Там process definition создаётся под каждый пул. А бизнес-процесс это несколько пулов.

С подменой понятий полностью согласен. Иногда из-за этого происходит недопонимание, хотя разговор может идти об одних и тех же вещах.
Пока я пришел к следующему критерию - если бизнес процессы по своей сути разные(кто -то выше говорил 1 продукт - 1 камунда) и каждый имеют свою модель данных, то целесообразно использовать несколько камунд. Если есть один глобальный бизнес процесс с единой моделью данных, но который поделен между участниками в виде отдельных пулов, то одна камунда.

Да, именно так

Надеюсь я вас правильно понял, поэтому решил на простом примере разобрать суть того, как лучше с моделью взаимодействовать.

Допустим возьмем простейший абстрактный процесс
1) Создается клиентом какая то заявка.
2) Заявка отправляется на внешний сервис и на основании ответа проставляется статус.
3) Сотрудником оставляется комментарий по этой заяки.

Итого у нас с точки зрения bpmn 2 user tasks, 1 service task

Далее что у нас происходит.
1. Стартовали процесс, не важно каким образом
2. UI запрашивает доступные задачи с бекенда, и на основании типа задачи отрисовывает формочку
3. Пользователь заполнил формочку. На ui сформировалось dto для этой формочки  и отправилось на бекенд запросом /complete-task(вот тут кстати вопрос как лучше делать, 1 универсальный эндпоинт complete-task или лучше на каждую таску свой эндпоинт, далее приводится пример с универссальным эндпоинтом )
4. На бекенде проверяется есть ли такая задача. Если есть, то для этой задачи:
1) Ищется подходящий класс dto, в объект которого конвертируется полученная json строка.
2) Определяется логика работы с dto для этой задачи. В данном случае создается сущность заявка со всеми полями и кладется в базу.
3) Идет обращение к taskService у камунды. То есть вызывается complite с id текущей таски и переменными. В данном случае переменная - id заявки.
4) Срабатывает task listener, который слушает task complete(Вот здесь уже есть отличие между юзер и сервис таск. Для юзер тасков нету делагатов, поэтому приходится лисенеров подключать). Этот слушатель берет id из процесса, достает заявку по этому id из базы, делает свою валидацию и ставит например статус NEW и записывает в бд новое значение.
5) На ui возращается результат операции, успешно или нет, + id следующих задач, если они появились за это время

5. В камунде срабатывает service task. Здесь ничего интересного, просто выполняется какая то логика. В конечного итоге ставится статус APPROVED.
6. Появляется новая таска. Перед отправкой ее на UI, наполняется необходимыми данными для отображения нужная дтошка и отправляется на ui.
7. После того как сотрудник заполнил данные, все отправляется на бэк, где сначала первым делом обновляется модель, а после чего вызывается  complete  у taskService для текущей задачи. После выполнения complete отдается ответ на ui.

Так получается?
Я привел пример синхронного взаимодействия. Хочется конечно асинхронности, но сначала хочу при таком раскладе разобраться в сути.

Федор, у вас второе имя не Иоганн?

Гутенберг который, книгопечатник

Попозже отвечу :)

Денис, нет, и даже не Достоевский 😄

)))

Жалко что митап сорвался, а так можно было на нем все обсудить) приходится теперь через перо выкручиваться

Митап не сорвался. Он будет, но 27 августа. ;)

Мы сделали так:
1) UI запрашивает список задач -> камунда отдает список согласно аутентификации текущего пользователя -> UI отображает список задач
2) пользователь открывает одну из задач -> запрос в камунду на получение задачи по ID -> камунда отдает ДТО -> UI по formKey понимает какую форму открыть, какие переменные из таска нужны (например ИД заказа) -> подтягивает по ИД заказа всю нужную инфу
3) пользователь заполняет форму и жмет завершить -> UI отправляет нужную инфу в сторонние сервисы и после этого дергает сервис completeTask в камунде с нужными дальше переменными

Камунде нужны переменные только для движения по процессу + ИД бизнес-модели (заявки в этом примере)

Нашел отличную статью, где парень объясняет почему модель данных должна существовать отдельно от процесса
Возможно кому то пригодится
http://airquill.io/2014/06/29/storing-data-in-processes/

Спасибо большое что поделились)
Как мне показалось, ваше решение позволяет по максимуму использовать возможности камунды. Судя по всему вы используете form service для форм и обращаетесь напрямую камунде по rest.
У меня сразу вопрос возник. А не слишком ли «умным» становится ui? Так как в него переносится много логики + он напрямую управляет процессом. И хорошая ли это практика в конечном итоге?

Наоборот, UI не управляет процессом, он говорит ему, какое решение принял пользователь и уже сам процесс решает куда ему идти