工作流模式详解之流程控制模式(2)——Parallel Split

1. 理论模型

　　此一模式，实际上是我我们常接触到的 AND 模型。

　　

　　值得注意的是这个定义来说一般B与C之间是并发的，实现上一般是两个不同的线程/进程。据我所知，许多自开发工作流引擎的公司，至今仍然不存在这一种AND的并发分支概念，而且这样的情况还不少。有兴趣的读者可以去了解一下，绝大部分电子政务的许多审批流程都是基于顺序和条件选择的，"并联审批"这一种说法极少用到。

2. 题外话

　　这一模式，也是一个基础的分支方式，稍有点名气的工作流引擎都可以直接实现。在国内，能实现这种模式似乎成了一个公司"技术脱贫"的标志。

　　何谓"技术脱贫"？

　　国内的中小软件企业，从业者有一种感觉比较强烈，就是需求的结构等于软件结构。因为我们的人才断层，因此从需求到软件这一层--系统分析和系统设计，基本没有找能担当的人。结果这个断层使得需求到编码的过程逐渐消亡。

　　而并联审批的实现，是稍微有点复杂，也比较间接。就技术上来说，涉及到并发的就存在这一个并发线程/进程的管理问题，如这些并发单元怎么组织管理其运行状态，如何通知不同的并发单元的交互，以及考虑到中途当机、重启恢复，资源争夺，并发冲突、死锁等等较为繁琐的细节。而这些技术上的细节，并不是实际业务需求的直接反映。

　　如果这个公司的技术底蕴不足，那会较为惧怕实现并发所带来的种种问题。更为严重的是领导层患有战略性近视，就会觉得耗费如此成本实现的这些东西，都不能直接反映在实际业务中，那还不如直接把实际需求退化成顺序模式和条件选择模式（根据以往的实践经验，尤其是我们电子政务的领域，许多时候退化成顺序模式也是一个不坏的选择）。而且业务上设计并发流程，也需要仔细考虑各项工作协调的细节问题。这一看来种种不利因素，实现这样一个并联分支所耗费这么高的成本，也不一定能对实际项目的应用有好的影响（这些影响尤其是降低成本、提高客户满意度方面都不太明显）。这种公司，一般都是蓝领水平充当白领职位（感叹啊，这代表了中国软件产业的现状，绝大多数的中小企业都存在这样的情况）。

　　显然上述的这种想法在小公司很普遍，尤其是偏向于商务运作的管理风格中尤为明显。所以如果一个公司愿意投入成本去实现这种并发模式，我认为这个公司起码在3个方面能表现出他的"技术脱贫"：首先是团队有技术实力解决并发应用所带来的问题；其次是领导层意识到了一些间接的东西所能带来的增长潜力；然后是这个团对明显已经有了需求与编码之间的衔接，不再简单的把需求结构直接映射成代码结构。

　　在我看来，能从表面开始深入理解这个行业，这种"思维脱贫"比"技术脱贫"更为重要。

3. 应用

　　这是一个很有弹性的模式。就这个模式独立来看，很简单。但是这一个模式引入到一个整体流程中，尤其是存在其他条件限制的业务中，可以延伸出复杂的流程结构。

　　技术上，一个AND并发分支，可能后续会出现同步合并、异步合并、鉴别器选择、线程合并等等方式（这些模式会在以后介绍），如果在分支上再引入循环模式（这个也在将来介绍），则会需要精确的考虑每个细节。

　　业务上，一个并发流程的设计，更牵涉到实际资源的分配、独占、争夺等问题。而因为工作并行需要的项目沟通协调也是一个需要仔细推敲的业务涉及过程。

　　不过这个模式本身看起来比较简单，就他与其他模式配合使用，和实际业务条件的限制下，就显得错综复杂。因此我们在这里只简单介绍了这个模式，后面介绍其他配搭模式的时候再详细解说。而不通模式的配合使用这一话题不属于任何一个模式，因此后面会开辟专栏文章介绍。