业务对象设计

业务对象设计的流程,我总结为了以下几个步骤:

  1. 理解业务流程,绘制简单的业务流程图

  2. 从简单的业务流程图中,大概提取出业务角色

  3. 分析各个业务角色之间的关系(一对一、一对多、多对多)

  4. 分析业务角色的

    • 属性

    • 操作

    • 状态

业务对象的状态

实际开发中,特别是复杂的业务系统,会包含复杂的状态变化。但是针对业务状态,很多开发人员甚至在需求开发阶段,业务的状态以及它的生命周期都理解的不清楚、不到位。无论是复杂的业务流程还是简单的业务流程,他一定拥有自己的状态变化,理清这些状态与状态变化,并对状态进行统一管理,会让业务对象更安全,代码健壮性也更高。

拿到一个业务对象时,首先需要分析他的业务状态有哪些,罗列出他的所有状态,并分析他的初始状态、终结状态,以及状态通过何种事件进行转换的,并将状态机图绘制出来。状态机图是后续代码开发的所有依据,没有清楚地状态机图,后续的代码就会变的异常混乱。

然后,将状态机图输出为代码时,需要对业务对象进行统一的管理,这有很多方式,但是其主要核心是控制状态机,让其所有的操作都合法:

  1. 控制业务对象在指定的状态下,只能进行指定的操作(状态幂等)

  2. 一个业务对象在某个状态下执行某个操作,一定要有确定的结果

当你讲业务的所有操作都控制住了,只要外层都调用这些API,那这个业务对象就永远不会出现令人疑惑的异常情况。

使用Manager层对业务对象进行控制

控制业务对象的一种我常使用的方式就是在Service层与Mapper层之间增加一个新的Manager层:

图 0

注意:

  1. Manager层是针对某个独立的业务对象进行生命周期管理的

  2. Manager层中的方法分为三种:

    1. 对状态没有影响的普通操作方法

    2. 对状态由影响的事件方法,他会让业务对象的状态转换到下一个状态

    3. 单纯的查询方法

  3. 为了状态的安全,Service层不可以直接调用Mapper操作更新数据库,这有可能导致数据、甚至是状态的不正确,从而导致以后发生一些奇怪状态的数据

  4. Manager中指涉及当前业务信息的变更,如果有关联的其他业务信息变更,需要由Service控制,交给另一个Manager处理。也就是说,Manager是独立的耦合性很低的,Service像是一个组装层。

  5. Manager层使用Model结尾的类作为参数返回值,也可以直接使用Entity,这里使用Model是因为多个业务对象可能映射到一张表中,或者数据库表中的字段因历史原因会有较多的垃圾字段,影响代码开发,故增加这个类型的对象,让业务对象更纯粹。

下面是一个有关合同对象的管理层,仅供参考:

ContractManager API

XXXXContractService

自动新增

保存、提交

保存、提交审批通过回调

保存、提交审批拒绝

保存、提交审批撤回

发起、编辑变更保存、提交

保存:

提交:

发起、编辑变更提交审批通过

最后更新于

这有帮助吗?