工作流概念

工作流。真正实施时应多看网上的例子，或开源项目。由于时间关系这里只记下我的一些基础想法。

---

与工作流有关的几个关键概念

• 工作流

  • 一个项目可以有多个工作流，对应多个工作。例如下订单流程、申请审核转正流程。
  • 一个业务应该对应一个流程，如果它有多种情况，应该多设置节点和路径即可。如果将同一个业务分成多个工作流，不方便统计，因为节点即业务对象的状态，而一个节点只能属于一个工作流。

• 阶段

  • 一个工作流有多个阶段，一个阶段可以有一个或多个节点。
  • 阶段的概念，只是方便用于显示给用户。因为实际节点有10多个的时候，页面显示会很拥挤，分成三到五个阶段会合适一点。
  • 当节点比较少时，可以直接使用节点的数据来显示。

• 节点

  • 一个节点对应一个业务对象的状态，而且是系统内部状态。
  • 显示给用户的外部状态，可以使用阶段的概念，也可以使用配置数据，给不同角色显示不同的名称。例如给卖家显示“已发货”，给买家显示“待收货”，当买家“待评论”，卖家则显示“已收货”。当然，一般来讲，使用统一的状态名才会比较好管理。

• 动作

  • 会有数据表记录着从一个节点执行了什么动作，会有什么结果，不同的结果会去到什么节点。（具体可参考状态机概念）

• 页面

  • 某状态要执行某动作，会去到哪些页面，这个是可以配置的。例如先get去到user/edit，再post去到user/edit-post。或者直接get去到 article/audit-post
  • 配置的好处是，当这些节点在工作流中调整位置时，我们可以不改页面系统就自动调整好流程了。
  • 缺点就是，一般来讲url数据是跟controller层在一起，而工作流核心的应该是业务层的东西。在工作流节点动作中配置url，会太耦合。需要开发人员知道在哪里调流程（URL就是控制流程的技术基础）。而且，需要为项目多个应用配置URL。

• 返回的数据格式

  • 在一个强耦合的工作流项目中，因为返回的东西要通知工作流框架下一步要怎样做，于是有三种情况：
    
    • 返回json给ajax请求
    • redirect url