并行任务与多进程
Parallel Tasks vs Multiple Processes
我正在尝试设计系统来实施我的复杂业务流程。考虑到以下情况，我正在尝试确定哪种方法更好。
流程中有多个并行任务。是将它们作为 BPMN 中的并行任务，如第一张图片中所述，还是如第二张图片中所述，让多个流程相互交互更好？
第二张图中解耦的系统让我可以自由地改变事物 w/o 太担心整个过程的后果。像微服务之类的东西。
我不受系统限制，但截至目前，我计划结合使用 Camunda 和自定义 API，根据业务逻辑生成触发器。
单进程
多进程
如果它是一个进程，则应将其建模为一个进程。所以你的第一个解决方案肯定是更好的。
如果你想稍微解耦一下：与其创建单独的进程，不如看看调用 activity 或子进程的概念。使用这些元素，您可以封装逻辑的某些方面并仍然对整个过程建模。
（顺便说一句：在您的第一张图片中，我会用并行网关替换包容性网关，因为您还使用并行网关拆分了流程。）
我了解到您的 objective 是将业务流程传达给系统用户。如果是这样，那么第一个图表在各个方面都“更好”，即
更接近BPMN标准 : 第2图中的三个进程没有相互通信。第二个进程如何知道付款已被接受？您将不得不添加信号或将三个进程放入单独的池中并让它们交换消息。
更理想。这三个过程将在您的第二个图表中同时启动。这意味着任务“Select 付款方式”可能会在您下订单之前开始（或更糟的是完成），这没有任何意义。作为业务用户（即您假设的目标受众），我会理解第一个图表，而第二个图表会给我谜语。第一个图表使业务逻辑更加明确和可读，这正是开发 BPMN 的目的：
"The primary goal of BPMN is to provide a notation that is readily
understandable by all business users..." (BPMN 2.0 Specification, page 1)
从您的描述来看，您的目标似乎实际上是为系统建模，并且您正在尝试调整业务流程设计以反映您的系统设计（例如，您说您更喜欢第二个图表，因为系统是解耦的，这使得更改更容易。但是两个图都没有描述系统或系统行为。第一个图可以通过使用 12 个系统来实现，而第二个可以使用一个系统来实现。
如果您真的必须这样做，那么您可以为三个系统中的每一个使用一个池，并按照上面的建议来回发送消息。但我宁愿保留第一个 BPMN 模型（可能会像 MuffinMICHI 建议的那样进行一些小的修正）并使用单独的 UML 序列或组件图，您可以在其中明确地对系统及其行为进行建模。
我正在尝试设计系统来实施我的复杂业务流程。考虑到以下情况，我正在尝试确定哪种方法更好。
流程中有多个并行任务。是将它们作为 BPMN 中的并行任务，如第一张图片中所述，还是如第二张图片中所述，让多个流程相互交互更好？
第二张图中解耦的系统让我可以自由地改变事物 w/o 太担心整个过程的后果。像微服务之类的东西。
我不受系统限制，但截至目前，我计划结合使用 Camunda 和自定义 API，根据业务逻辑生成触发器。
单进程
多进程
如果它是一个进程，则应将其建模为一个进程。所以你的第一个解决方案肯定是更好的。 如果你想稍微解耦一下：与其创建单独的进程，不如看看调用 activity 或子进程的概念。使用这些元素，您可以封装逻辑的某些方面并仍然对整个过程建模。
（顺便说一句：在您的第一张图片中，我会用并行网关替换包容性网关，因为您还使用并行网关拆分了流程。）
我了解到您的 objective 是将业务流程传达给系统用户。如果是这样，那么第一个图表在各个方面都“更好”，即
更接近BPMN标准 : 第2图中的三个进程没有相互通信。第二个进程如何知道付款已被接受？您将不得不添加信号或将三个进程放入单独的池中并让它们交换消息。
更理想。这三个过程将在您的第二个图表中同时启动。这意味着任务“Select 付款方式”可能会在您下订单之前开始（或更糟的是完成），这没有任何意义。作为业务用户（即您假设的目标受众），我会理解第一个图表，而第二个图表会给我谜语。第一个图表使业务逻辑更加明确和可读，这正是开发 BPMN 的目的：
"The primary goal of BPMN is to provide a notation that is readily understandable by all business users..." (BPMN 2.0 Specification, page 1)
从您的描述来看，您的目标似乎实际上是为系统建模，并且您正在尝试调整业务流程设计以反映您的系统设计（例如，您说您更喜欢第二个图表，因为系统是解耦的，这使得更改更容易。但是两个图都没有描述系统或系统行为。第一个图可以通过使用 12 个系统来实现，而第二个可以使用一个系统来实现。
如果您真的必须这样做，那么您可以为三个系统中的每一个使用一个池，并按照上面的建议来回发送消息。但我宁愿保留第一个 BPMN 模型（可能会像 MuffinMICHI 建议的那样进行一些小的修正）并使用单独的 UML 序列或组件图，您可以在其中明确地对系统及其行为进行建模。