Роутер имеет смысл как входная точка для фронтов, типа gateway. Когда фронтов много, а процессы одни. И мы не хотим из заставлять знать куда там что слать. Но это только для старта процессов

У нас процессы скорее ставят задачи людям. Т.е. фактически у нас пока есть логика в сервисах, и процесс работы, по которому работают люди. BPMS используется как постановщик задач на бэкенд.

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

Фактически у нас нет системных процессов, чтобы мы проектировали взаимодействие с сервисом каким-то.

А в чем переиспольщование тогда? В постановки задачи человеку?

Для людей нужно делать отдельный сервис задач, с формами и контекстами, куда скидывают задачи процессы, вот как тут у пацанов сделано https://bpmn2.ru/blog/goldman-sachs-bpmn-camunda

Денис, посмотрю, спасибо.

Ну мы где-то так и делаем. По сути мы берем userTask из bpms, регистрируем в бэке, к нему цепляем на бэке логику, формы, валидацию данных. Далее после выполнения задачи в процессе выбирается, какую задачу ставить дальше, ждать ли каких-то сигналов с бэкенда. Т.е. задача активна пока оператор выполняет предписание. Как только он закончил - работает bpms и взаимодействует с разными сревисам, ждет чего-то если это необходимо.

Ну и отлично. А а каком тогда переиспольщовании процессов речь? Если процессы правильно поделены по бизнес направлениям,  а под них подолжены общие сервисы, то по своей природе у одного процесса не будет желания запустить процесс их другого продукта.

@Kotskin ну если предположить что на каждого типа клиента в рамках каждого продукта у меня свой комплект процессов обслуживания - все ок. Но каждый такой набор процессов будет на 60-70% (если не больше) повторяться в разных местах в зависомости от обстотельств. Плюс чтобы поддерживать такой объем логики понадобится на каждый такой набор иметь своего аналитика и, возможно, разработчика. Сложно будет поддерживать консистентность в логике которая будет повторяться в большинстве флоу. Хотелось бы всего этого избежать и иметь только уникальную логику. А на выходе у меня получится условно N процессов в которых K% логики дублируется.

Отсюда и мысль: т.к. глобально процессы для каждого типа клиентов в рамках каждого продукта на 80-90% похожи, и тонкости реализации начинаются в деталях, поделить процессы на атомы с минимальной логикой, и атомы переиспользовать, когда это возможно. Могу нарисовать суть в картинке.

ну вот эта "похожесь" и должна жить в отдельных сервисах, которые вызываются процессами.  Сам процесс не является таким сервисом.

Ну там всем надо смс-ки слать. Нужен сервис смсок с хорошим апи, все процессы его вызывают, но снаружи параметризиуют его поведение - передают тест смски и дату отправки, например.

т.е. понятно что там под капотом у смсок буду, возможно, тоже свои процессы - таймзоны, очереди отправок, выбор более дешевого провайдера и т.д. но это всё за границами продуктового процесса, и продуктовой системы соответственно

добрый день, хотел получить рекомендацию по построению схемы с саб процессами. Предположим у меня есть основной процесс, который может запускать N количество сабпроцессов, при этом эти сабпроцессы в течении своего исполнения кидают сообщения в основной процесс для кординации выполнения, т.е основной процесс завершается всегда после завершения саб процессов.
Какой лучше выбрать подход для этого кейса: а) для основного процесса и саб процесса я использую отдельные схемы и для каждой такой схемы запускаю отдельные инстансы?
б) я использую одну схему главного процесса и внутри использую non interrupting event sub processes? (см картинку)

В рамках одного процесса нельзя слать сообщения самому себе, по фен-шую

по феншую нельзя, но технически можно?

Был написан нами простенький процесс в свое время, но он полностю не удовлетворяет вашим задачам. Так смысл в чем: процесс один а используется разными людьми и по сути в gui тоже по разному отображается, в процессе значение всех переменных задается при старте нашим бэком вплоть до candidate grope/

сам процесс очень прост

к схеме прошу не придираться писалась на первых этапах освоения))