2.设计不带网关的流程
有些人不喜欢网关，他们认为网关使流程图过于全面甚至膨胀，他们宁愿没有这些钻石。虽然网关是可选的—您可以代替直接使用任务建模XOR、and和or网关的逻辑—但必须小心。
网关几乎不可能完全消除
图2.1演示了or分割和xor合并的替代方法。
上面的流程模型和下面的流程模型是等效的，但是上面的模型显示了直接路由到task 4的两个流。它还用条件流符号表示or分割:连接到任务1的小菱形。条件流符号只能连接到任务或子进程，并且只能作为输出。它们不能用于网关或事件。
有这样一个问题:如果两个条件中只有一个适用，那么一切都没问题，但如果两个条件都适用，它们将在or分割中生成两个令牌，因此由于xor合并，它们将两次触发task 4。这并不一定是错的，但可能不是故意的。这就给我们带来了第一个问题:
1、在没有网关的情况下，我们无法对同步(即合并)建模。
2、第二个问题是我们不能合并条件检查。由于中间事件的存在，我们无法在没有网关的情况下表示图2.2所示的流程逻辑。
图2.2:组合的异或网关。
3、第三个问题是条件流遵循与or分割相同的语义。换句话说，所定义的条件不能相互排除。因为or分割与随后的xor分割是兼容的，这并不重要，但是建模者和那些使用他们的图的人需要意识到这一点。否则，根据我们的经验，很快就会产生误解。
一直使用网关会更好吗?不，也没有这个必要。例如，一个简单的循环，在没有异或合并的情况下会更好，因为它不会让没有经验的人感到迷惑。而且因为bpmn允许从开始事件到结束事件的多个流，图可以很好地压缩。为了说明这一点，我们在图2.3中对带有和不带有网关的流程进行了建模。(是的，从技术上讲，这些模型并不完全相同:上面的模型在语法上包括xor网关，因此必须使用多个路径。它要求条件1和条件2不能同时发生。在较低的模型中，情况并非如此，两种情况都适用。)
图2.23:这两个模型(几乎)描述了相同的过程。
本文会持续更新，欢迎关注，技术支持：盘古BPM