Параллельные задачи против нескольких процессов

Question

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

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

Системы, разъединенные во второмДиаграмма дает мне свободу изменять вещи, не беспокоясь о последствиях для всего процесса.Что-то вроде микросервисов.

Я не ограничен системой, но на данный момент я планирую использовать комбинацию Camunda и пользовательских API, которая генерирует триггеры на основе бизнес-логики.

Single Process

Несколько процессов

Answer 1

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

(Кстати: на вашем первом рисунке я бы заменил включающий шлюз на параллельный, потому что вы также разделили поток с параллельным шлюзом.)

Answer 2

Я понял, что ваша цель - донести бизнес-процесс до пользователей системы. Если это так, то первая диаграмма во всех отношениях «лучше», то есть она

• ближе к стандарту BPMN : три процесса на 2-й диаграмме не связаны друг с другом. Как второй процесс узнает, что платеж принят? Вам придется добавить либо сигнал, либо поместить три процесса в отдельные пулы и заставить их обмениваться сообщениями.

• более желательно . Три процесса будут запущены одновременно на вашей второй диаграмме. Это означает, что задание «Выбрать способ оплаты» может начаться (или, что еще хуже, закончиться) еще до того, как вы разместите заказ, что не имеет никакого смысла. Как бизнес-пользователь (т. Е. Ваша предполагаемая целевая аудитория) я бы понял первую диаграмму, тогда как вторая дала бы мне загадки. Первая диаграмма делает бизнес-логику более явной и удобочитаемой, для чего и была разработана BPMN:

"Основной целью BPMN является предоставление обозначения, которое легко понятен всем бизнес-пользователям ... "( Спецификация BPMN 2.0, стр. 1 )

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

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