dingyuan

情景： 法院一般对一个案子有以下一个流程

       立案à分案à审判à结案

其中

立案阶段 ---- 立案人员

分案阶段 ---- 分案人员

审判阶段 ---- 法官

结案阶段 ---- 法官

上述的立案人员，分案人员，法官各自都是一个Group

一个案件加入有8个属性

a b c d e f g h

每个阶段不同组的人员处理案件的属性为

立案阶段 ---- 立案人员 -- a b

分案阶段 ---- 分案人员 – c d

审判阶段 ---- 法官     --e f

结案阶段 ---- 法官     --g h

一．           需要工作流的本质

根据上述的情景，试想一下没有工作流的情况，我们一般的实现方式

为了将问题简单化

定义一个model为Case --- 案件

其中Case里面有一个属性，专门纪录案件状态，为state

在立案状态，state =’L’

  分案状态，state =’F’

  审判状态，state =’S’

  结案状态，state =’J’

还有一个与案件相关的Repository，CaseRepository

以及处理案件的用例ProcessCaseService

我们只分析处理案件用例里面的3个子用例

1．    取得相关案件    List getCases(String userName)

2．    改变案件状态    void changeCaseState(String userName)

3．    由立案人员建立一个案件 void createCase(String userName)

4．    处理案件        void dealCase(BussinessDomain business)

还有一个处理用户和用户组的用例ProcessOrganizationService

里面的相关的用例有

1．取得相关的用户组 String getGroupName(String userName)

立案人员有3个用例与之相关

1．  只获得与立案阶段相关的案件

2．  将案件状态改变为分案状态

3．  建立一个处于立案阶段的案件

4．  处理立案阶段案件的相关数据

分案人员同样与立案人员有相似的用例

整一个案件的处理过程，也就是整一个处理案件的主线

立案à分案à审判à结案

而这一个过程，涉及到的相关的业务逻辑有

1．只获得属于自己处理阶段的相关案件

2．改变案件状态

3．案件状态对应的groupName

当业务逻辑发生变化的时候,比如有的地方法院实现分案，后立案

分案à 立案à审判à结案

那么，针对这个法院，我们就要对我们原来存在的系统进行代码的修整

原来是立案人员建立一个案件

现在由分案人员建立一个案件

需要修正的代码是void createCase(String userName)

这个时候，又有的地方法院分案阶段处理的案件属性是a和b,而不是原来的c和d

需要修正的代码是void dealCase(BussinessDomain business)

当dealCase业务逻辑复杂的时候，所需要修改的代码是海量的

这时候，又有的法院的案件处理是分案人员负责立案，立案人员负责分案

需要修正代码的地方是

void changeCaseState(String userName)

void createCase(String userName)

void dealCase(BussinessDomain business)

这里只是法院的业务流程，每个行业都有每个行业自己的业务流程，为了将对业务流程的处理这一部分，抽取出来，并且尽可能的少修改代码，就有了工作流引擎的产生

二．           wfmc定义的域模型

业务流程是什么？业务逻辑的那些部分是属于业务流程？哪些业务逻辑是要划分给工作流引擎的呢？

1．  什么是需要根据实际情况系统要发生改变

根据情景

(1) 一般法院的案件处理流程为

立案à分案à审判à结案

而有的法院为

   分案à 立案à审判à结案

这4个阶段的先后顺序会发生变化

(2)       有的地方法院分案阶段处理的案件属性是a和b,而不是原来的c和d

不同阶段需要处理的案件相关数据发生变化

(3)       有的地方法院是分案人员负责立案，立案人员负责分案

角色所要负责处理的相应阶段的事情发生了变化

这个情景只是法院的情况，不同的领域，业务流程也不一样。为了将所有领域的业务流程的抽取出来，标准化组织对此做出了明确的定义，并定义了元数据模型，也就是我们开发过程中的业务流程相关的model类

如下图