业务对象设计
业务对象设计的流程,我总结为了以下几个步骤:
理解业务流程,绘制简单的业务流程图
从简单的业务流程图中,大概提取出业务角色
分析各个业务角色之间的关系(一对一、一对多、多对多)
分析业务角色的
属性
操作
状态
业务对象的状态
实际开发中,特别是复杂的业务系统,会包含复杂的状态变化。但是针对业务状态,很多开发人员甚至在需求开发阶段,业务的状态以及它的生命周期都理解的不清楚、不到位。无论是复杂的业务流程还是简单的业务流程,他一定拥有自己的状态变化,理清这些状态与状态变化,并对状态进行统一管理,会让业务对象更安全,代码健壮性也更高。
拿到一个业务对象时,首先需要分析他的业务状态有哪些,罗列出他的所有状态,并分析他的初始状态、终结状态,以及状态通过何种事件进行转换的,并将状态机图绘制出来。状态机图是后续代码开发的所有依据,没有清楚地状态机图,后续的代码就会变的异常混乱。
然后,将状态机图输出为代码时,需要对业务对象进行统一的管理,这有很多方式,但是其主要核心是控制状态机,让其所有的操作都合法:
控制业务对象在指定的状态下,只能进行指定的操作(状态幂等)
一个业务对象在某个状态下执行某个操作,一定要有确定的结果
当你讲业务的所有操作都控制住了,只要外层都调用这些API,那这个业务对象就永远不会出现令人疑惑的异常情况。
使用Manager层对业务对象进行控制
控制业务对象的一种我常使用的方式就是在Service层与Mapper层之间增加一个新的Manager层:

注意:
Manager层是针对某个独立的业务对象进行生命周期管理的
Manager层中的方法分为三种:
对状态没有影响的普通操作方法
对状态由影响的事件方法,他会让业务对象的状态转换到下一个状态
单纯的查询方法
为了状态的安全,Service层不可以直接调用Mapper操作更新数据库,这有可能导致数据、甚至是状态的不正确,从而导致以后发生一些奇怪状态的数据
Manager中指涉及当前业务信息的变更,如果有关联的其他业务信息变更,需要由Service控制,交给另一个Manager处理。也就是说,Manager是独立的耦合性很低的,Service像是一个组装层。
Manager层使用
Model结尾的类作为参数返回值,也可以直接使用Entity,这里使用Model是因为多个业务对象可能映射到一张表中,或者数据库表中的字段因历史原因会有较多的垃圾字段,影响代码开发,故增加这个类型的对象,让业务对象更纯粹。
下面是一个有关合同对象的管理层,仅供参考:
ContractManager API
XXXXContractService
自动新增
保存、提交
保存、提交审批通过回调
保存、提交审批拒绝
保存、提交审批撤回
发起、编辑变更保存、提交
保存:
提交:
发起、编辑变更提交审批通过
最后更新于
这有帮助吗?