并行任务与多个进程

Question

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

这些是流程中一部分的多个并行任务。如第一幅图所示，将它们作为BPMN中的并行任务更好，还是如第二幅图所示，具有多个相互交互的进程？

第二张图中解耦的系统使我可以自由地进行更改，而不必担心整个过程的后果。诸如微服务之类的东西。

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

单一过程

多个过程

Answer 1

如果这是一个进程，则应将其建模为一个进程。因此，您的第一个解决方案肯定是更好的解决方案。 如果您想使事情脱钩，请执行以下操作：而不是创建单独的流程，而是查看调用活动或子流程的概念。使用这些元素，您可以封装逻辑的某些方面，并仍然为整个过程建模。

（顺便说一句：在您的第一张图片中，我将并行网关替换为包含网关，因为您还使用并行网关拆分了流量。）

Answer 2

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

• 更接近BPMN标准：第二张图中的三个流程没有相互通信。第二个流程如何知道付款已被接受？您将必须添加一个信号或将这三个进程放入单独的池中，并使它们交换消息。

• 更可取。这三个过程将在第二张图中同时启动。这意味着“选择付款方式”任务可能在您下订单之前就开始（或更糟糕的完成），这毫无意义。作为业务用户（即您假定的目标受众），我会理解第一个图表，而第二个图表会让我感到困惑。第一个图表使业务逻辑更加明确和易读，而这正是BPMN开发的目的：

  

“ BPMN的主要目标是提供一种易于使用的符号   所有业务用户都可以理解...”（BPMN 2.0 Specification, page 1）

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

如果确实需要，则可以为三个系统中的每个系统使用一个池，并按照上述建议来回发送消息。但是，我宁愿保留第一个BPMN模型（也许会进行一些较小的更正，如MuffinMICHI所建议的那样），并使用单独的UML序列或组件图，在其中明确地对系统及其行为进行建模。