并行任务与多个进程

Question

我正在尝试设计系统来实现我复杂的业务流程。考虑到以下情况，我试图决定哪种方法会更好。

多个并行任务是流程的一部分。将它们作为BPMN中的并行任务更好，如第一张图像中所述，或者有多个进程如第二张图像中所描述的那样相互交互？

在第二个图中解耦的系统让我可以自由地改变事物，而不必担心对整个过程的后果。像微服务一样的东西。

我不受系统的限制，但截至目前，我计划使用Camunda和自定义API的组合，这些API根据业务逻辑生成触发器。

单一过程

多个进程

Answer 1

如果它是一个进程，则应将其建模为一个进程。所以你的第一个解决方案是更好的解决方案。如果你想稍微解耦一下：不要创建单独的进程，而是查看调用活动或子进程的概念。使用这些元素，您可以封装逻辑的某些方面，并仍然可以模拟整个过程。

（顺便说一下：在你的第一张照片中，我会用并行网关替换包容性网关，因为你也用并行网关分割流量。）

Answer 2

我了解您的目标是将业务流程传达给系统用户。如果是这样，那么第一个图表在各方面都“更好”，即它是

• 更接近BPMN标准：第二个图表中的三个过程不相互通信。第二个流程如何知道付款已被接受？您必须添加信号或将三个进程放入单独的池中并使它们交换消息。
• 更可取的。这三个过程将在您的第二个图表中同时启动。这意味着“选择付款方式”任务可能会在您下订单之前开始（或更糟糕的完成），这没有任何意义。作为商业用户（即您假设的目标受众），我会理解第一个图表，而第二个会给我一些谜语。第一个图表使业务逻辑更加明确和可读，这正是BPMN的开发目的：

“BPMN的主要目标是提供一个易于被所有商业用户理解的符号......”（BPMN 2.0 Specification, page 1）

根据您的描述，您的目标似乎实际上是对系统建模，并且您正在尝试调整业务流程设计以反映您的系统设计（例如，您说您更喜欢第二个图表，因为系统已解耦这使得更改变得更容易。但是这两个图表都没有描述系统或系统行为。第一个图表可以使用12个系统实现，而第二个图表可以用一个系统实现。

如果你真的不得不那么你可以为你的三个系统中的每一个使用一个池，并按照上面的建议来回发送消息。但我宁愿保留第一个BPMN模型（可能还有MuffinMICHI建议的一些小修正），并使用单独的UML序列或组件图表，您可以在其中明确地模拟系统及其行为。