Я имел ввиду в самой схеме. чтобы не несколько ruleTask в схеме было, а один. Но фактически у меня не получается никак построить, чтобы схема от многого к одному шла. Она у меня деревом разворачивается наоборот :(

Явно что-то делаю не так)

Тогда в принципе как альтернатива - можно dmn-ки вынести в sub process или call activity. Тогда на схеме будет 1 «квадратик»

В дмн есть чейнинг решений

Вам ваш гейтвей надо выродить в данные

И вызывайть внутри drd головное решение, оно вызовит дочерние

В dmn отсутствует инстанс как таковой, поэтому активности невозможны, поэтому логику можно завязывать только на данные. В рамках данных можно гейтвей сэмулировать булевой переменной

Умгу. Понял. Надо покрутить в голове. Не привык мозг так оперировать данными.

Спасибо.

Может и не надо, легко переинженерить

Вот советы про бизнес правила хорошие

Это откуда?

Из книги real world decision modeling with dmn

Или может из презентации к ней

Понял, спасибо!

и/или требования компании на проде иметь поддержку

Парни, приветствую! У кого есть практика разработки роутинговых процессов? Когда основной процесс бьется на совсем атомарные и после завершения атомарного процесса флоу замыкается на роутер. Роутер принимает решение куда дальше. Роутеров таких много и они выступают в роли распределительных центров для глобальных процессов.

Задача такой архитектуры: У нас много бизнес юнитов, которые имеют схожие процессы в целом, но различные в нюансах. Эти юниты хотят сами проектировать свои процессы независимо друг от друга. Нужно развязать их и дать возможность работать отдельно друг от друга, но при этом не хочется делать N наборов процессов равный количеству бизнес юнитов. Плюс в слчае чего нам нужно быстро развернуть новый юнит, работающий по стандартным процессам с возможной постепенного переезда на кастомную логику.

Решение которое планируется получить: Для каждого глобального процесса мы делаем роутер И набор common атомарных процессов, которые могут переиспользоваться всеми юнитами при желании. Если юнит хочет персональную логику в атомарном процессе, то делает свой атомарный процесс согласно правилам описанного черного куба (что нужно получить на вход, что отдать, какие сигналы принимать и какие отдавать) и подключает его к роутеру. Роутер BPMN + DMN.

Внутри своего куба юнит получает возможность пилить логику как хочет + независимо от остальных ее обновлять.

Прокомментируйте решение, пожалуйста. Какие возможны риски, какие есть практики решения похожих задач?

Так ваш роутер это CMMN

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