workflow 本质论

       workflow的存在似乎是个怪物,以一套复杂的流程操作原语来定义一个流程,而这个流程却与数据产生说不清又道不明的关系, 不能说数据与流程无关,也不能说数据域流程有关,处于是与非尴尬的边界上,至于面向流程的编程的说法,更是莫名其妙,何谓面向流程?难道一切都是流程?肯定不是.难道流程能代表所有系统的核心?恐怕也不是.那流程究竟是什么呢?真的它普适于所有的系统吗?计算机里的流程与实际的业务流程是一致的吗?当然不是,然而为什么我们总能清晰地感觉到有一种共性的东西存在呢?

 

     必须承认这种感觉是非常尴尬的,无视workflow或者以workflow为中心去做需求分析与架构设计都是同样的让人痛苦,因为不承认workflow我们却能从需求中看出来, 承认workflow却又造成架构设计处处受限,这到底是什么原因造成的呢?

 

    其实,如果我们先抛开workflow, 远远地看业务系统本身, 理解业务系统本身, 然后再从中抽象出workflow来, 也许才能地看清楚workflow的本质.

 

    当我们抛开workflow, 回头再看业务系统, 那么我们首先看到的, 是业务模型, 更仔细看, 支撑业务模型的, 是领域对象, 是一个有机联系在一起的超大的数据结构体系, 在面向对象的世界里, 就是一个个相互深刻关联的类, 系统的根本要求就是保证这个体系的完整性和一致性, 不要出现业务数据的不一致, 其次才是要保证性能等.

 

    我们知道每一个业务系统实际上是与相关业务人员关联的, 就是涉众, 在系统里, 就被相应映射为角色用户体系,而这正是workflow存在的源头.

 

    但是在这里,先抛开workflow的一系列概念, 看看绝大多数系统里都有的用户角色的权限控制体系, 仔细想想, 其实这不正是最简单最常见的工作流程吗?数据往往在一个功能里存在之后,才能在另外一个功能里出现, 而功能却由不同的人拥有, 实际上就是数据实现了流转.

 

    因此, 从这个观点上说, workflow就是对业务系统的一种常规抽象, 但是这样很难说抓住了问题的本质, 因为workflow可以控制的更为精细, 细致到每一条数据都能产生不同的走向. 实际上, 完全可以把这种流转走向看做是数据的生命旅程, 而从这一点上再回到业务系统本身上来, 那么我们可以得出一个站得住脚的结论:每一个业务数据都是有生命周期的.

 

    这样,我们才可以明确地区分出两个概念, 业务数据和业务状态, 业务数据是系统核心价值, 是客户最关心的部分, 业务状态则系统控制的核心,是客户所希望系统完成的而不是客户所关心的部分, 而正是这二者的差异, 往往造成我们在做需求分析的时候, 业务数据的资料远多于业务状态的资料, 后者的获取难度也远大于前者, 结果造成架构设计的缺失.

 

    然而事情诡异的地方就在于业务数据和业务状态是混合的, 是胶合在一起的, 数据与状态如同父与子的关系, 简单时往往不分家, 复杂时往往分家, 但却又是在同一个大家庭里相互影响, 由此可见, 虽然从概念上二者容易区分, 然而实际上却是一种尴尬的存在, 虽然业务数据要比业务状态来得持久, 但是本质上, 他们都是系统数据, 而且是相互关联的数据.

 

    更为难堪的是, 对于同类型的业务数据, 其业务状态却是可以完全不同的! 问题从此变得难以琢磨, 你说不准这业务状态到底是不是客户所需要的, 因为客户自己都根本没有注意到业务状态的复杂多变, 于是架构师们试图超越一切不确定因素的本能就被发挥出来了, 弄一个万能的管理这种状态的玩意出来, 于是, workflow开始破茧蜕变, 最后演变成今天的样子.

 

   这么看来, workflow的本质, 就是企图解决所有业务状态控制需要的一种架构思想. 是的, 这是一个架构思想, 不是给客户用的, 而是给程序员减轻一下重复劳动而产生的.

 

   而实际上, workflow也的确在很多方面做到了解放程序员, 但是却是以对业务系统理解的更大迷惑为代价的: workflow里有多少业务数据?...

 

   但更为危险的是, workflow构造的思维模式会给人一种它适合于所有的业务系统的错觉, 使得系统构造如同黄金手铐, 受益于它又受制于它!(我深刻地怀疑打造这副黄金手铐根本就是故意的)

 

    如果我们不去考虑workflow的思维模式,换一种方式呢?

 

    实际上, 业务数据和业务状态是紧密关联在一起的系统数据, 只有将系统数据分割成属于不同类型涉众的数据子集, 才能看到workflow背后的本质:

   

    每一类涉众或每一个人都有自己私人的业务数据集合, 每个人都有处理自己私人数据集合的相关权力, 这个处理除了增删改查之外, 还有转发的权利, 实际上, 是别人的业务数据集合开放给自己(增删改查)的部分权利.

 

    从面向集合的分析建构方法来看, 所有的问题无非是要做到2点: 1, 数据集合必须是清晰归属于相关涉众的(涉众也如类一样可继承); 2, 每一类系统数据必定拥有附加的动态结构, 这个动态结构不仅可以看到相关涉众, 而且可以重建和回退过程.

 

   因此, 从面向集合的观点看来, 其实workflow是多余的, 甚至由于各种workflow版本的实现千差万别, 不当使用workflow的思想甚至是非常有害的.