也谈流程模型的层次设计

07年的时候，去了家国外的工作流厂商做研发，就此和工作流打上了交道。中间断断续续一直在搞和流程相关的东西。去年秋天换了份工作，花了一年和team一起搞了套全新的流程平台，中间磕磕碰碰不少，但也算小有所获。赶上正月里闲暇时间较多，把一些心得分享出来，一来算是对过往的思想有个小结，二是多听听大家的意见和建议，开拓思路，共同进步。

 

由于07年之前从事的工作并没有涉及太多工作流，因此当进入这家公司后，其产品的设计思想对我的影响很大，随后接触了微软的WF，以及基于它搭建的BizTalk：Ochestration，MOSS Workflow以及其他一些工作流产品，对于后续的设计风格都有这不同程度的影响和补充。

 

关于流程层次，园子里的WF元老级人物 @WXWinter 有过好几篇文章着力介绍：

流程的层次：http://www.cnblogs.com/foundation/archive/2009/02/06/1385122.html 

同一流程多种状态：http://www.cnblogs.com/foundation/archive/2009/02/24/1397111.html 

 

WXWinter兄对其论述的已经相当充分，很多文章都让我受益匪浅，因此本文只算是对其思想的一种补充。流程层次决定了流程模型的设计，也就直接决定了这套流程系统适宜处理的流程模式（Workflow Patterns），开年第一篇的标题，就叫做“也谈流程模型的层次设计”吧。

 

通常的流程模型，我们一般分为2层：流程-节点（或者叫：活动）：

流程在业务上被用来表述一个具体业务场景、业务流程（比如：采购流程、报销流程等）。

而节点则是对一个特定业务动作的封装（比如：发邮件、审批、付款等）。

业务动作是可以复用的。一组业务动作的有序组合构成了一个业务场景；一个或多个业务场景的组合构成了一支业务流程。

 

通常我们在设计流程的时候，很少会清晰的对业务场景进行细分（主要也是流程不复杂），因此最常见的流程设计模式就是：一组代表不同业务动作的节点，通过转换逻辑（通常是连接线），构成了一支业务流程。

但这样带来的问题，就是WXWinter兄提到的：结构不清晰，职责没有明显的边界和划分，这是从业务的视角看会带来的弊端。

而从流程模型的技术视角方面，过度细节的暴露也不利于流程的清晰。我们设想一个简单的请假审批流程（只列正向流程）：

其业务的表述一般是：【提交请假单】 -> 【领导审批】 --(同意)--> 【通知通过】。

OA集成度较高的，还会从传统的审批流（Human-Human WF）转为人机流（System-System WF)：

【提交请假单】 -> 【领导审批】 --(同意)--> 【修改HR系统剩余天数】 -> 【通知通过，并告知剩余天数】 

当我们用二层模型去设计的时候，真实的流程图可能是： 

 【开始】 -> 【创建代办任务】 -> 【发送审批通知】 --(同意)--> 【写数据库/调用API】 -> 【读数据库/调API并赋值于变量】 -> 【构造邮件内容，发送邮件】

 

继续之前先说明一下：这里大家可能会觉得 【创建代办任务】和【发送审批通知】应该被放在一起实现，并合为一个节点，叫审批。不过如果从可复用性的角度和扩展性角度看，建议拆开，而通过易用性改进将其整合起来。不然以后如果用户今天是发邮件，明天发短信，后天发微博，会很麻烦（除非你在审批中实现了MessageProvider）。

 

回到正题，从上面的实际流程上，我们可以看到几个问题：

 1）【创建代办任务】和【发送审批通知】实际上属于同一个业务场景。

 2）【写数据库/调用API】和【读数据库/调API并赋值于变量】过于技术化。

 3）节点膨胀（业务设计：4，技术实现：6）  

为了解决这个问题，有多种方式，最简单有效的莫过于放弃或降低业务动作的复用性，实现【审批】这个特定节点，实现【修改HR系统字段】这个特定业务动作（业务具体化）。如果是项目实施的话很方便，但对于业务平台或者产品来说就降低了灵活度。

 

第二种方式是引入组（Group）或者模版（Template、Snippet）的概念：

由于这两个概念在各类产品比比皆是（比如PPT），不多详述。只是组只能做归纳，模版只能做简单复用，随着系统的复杂度和流程数量和节点数量的增加，在另一方面降低了系统整体的可用性。

第三种方式是引入容器（Container）这一概念：

容器可以封装多个业务动作，其相对于组最大的区别，在于它自身更像一个接口，其对内和对外都有一定的可交互特性在里面，仿佛微观层面的Facade模式一样。这里举出两个产品的容器概念：

1）微软的WF：其本身是二级模型，但是活动（Activity）可以包裹其他的活动，因此一个Sequential或者If、FlowChart都是一个容器。其本身即可将实现细节封装起来，同时通过Argument和Variable来有效的和内外进行数据交互。

2）K2：K2产品本身即三层模型结构：流程（Process）- 活动（Activity ）- 事件（EventWizard)。其事件即用来实现特定的业务动作，而活动则更像是一个功能容器，一个活动可以包裹多个事件，以此实现一个特定的业务场景。

 

我个人也很推崇容器的概念，因为这种模型带来的直接好处便是：业务人员只关心其业务流程的设计（只绘制流程和容器），而IT人员则对其进行业务动作的配置和补全。 以此来实现业务和IT更流畅的沟通。

 

还有一些其他的方式：

比如节点上可以配置多个扩展服务调用，但是这样不够直观，我们要隐藏细节，但是也要能够方便的展现细节。

还有便是子流程调用，但这已经超出本文的讨论范畴，属于广义上的业务流程交互，不多讨论。 

 

本文主要想讨论一些二层模型和三层（容器）乃至多层模型对业务表述、沟通和支撑的影响。 第二次发技术文，一口气写完，很多想法可能还推敲不够，希望能够多和大家交流。我除了博客园，最常用的就是新浪微博：@杨二毛SZ

 

希望能够结交跟多朋友，祝大家新年快乐！

转载于:https://www.cnblogs.com/SharpMoon/archive/2012/01/31/workflow-model-design.html