服务类系统业务理解

前言:公司项目属于服务平台类，半年了，谈一谈对服务类系统的理解😗

定义

服务平台最核心的定义就是需要确定一个概念为核心，驱动整个服务功能的运行。

例如，服务于全国商城的营销服务平台：

确定用户：商城[第三方] 指的是 商城 - 系统 - 集团

确定使用原因：营销服务[与集团物流数据对接]

确定使用范围：商城的用户

那么通过使用人-使用原因-使用范围，可以初步定义，与商城对接的用户是业务的起点。

当使用范围[用户]有了之后，才能以此为根节点驱动。

但是，使用范围是不能作为业务主键驱动的。

即使创建用户，也不能体现出任何的营销服务的概念，所以继续往下。

确定使用意义：营销服务的意义在于，便捷商城营销的过程。所以当商城的用户有了，则需要分配一张表，用于登记这个用户在营销过程中的体现。

即服务单概念，营销服务的核心。

但是这个例子并不清晰

那么还例如，服务于学生的内务服务平台[贴近生活]：

确定用户： 学生[第三方] 学生 - 平台 - 内务部

确定使用原因： 内务服务

确定使用范围： 学生的寝室？卫生间 等等

一样的，通过使用范围可以明白，需要一个东西去承接初始范围节点之后的业务过程，这就是业务驱动节点。

即，内务登记单。😃

但是这些都只是个人理解。

业务实施

以上述的营销服务平台为例：

当服务单被创建，则说明业务已经开始[建档]。

营销服务分别有以下几个节点：服务单创建 - > 服务单审核 - > 下属或同事转接服务单 - > 审核 -> .....- > 当前服务单数据到集团 -> 集团审核，通过服务单信息，向商城发放本次营销服务的绿灯 - > 商城接受 - > 反馈给用户[商城的用户]

如果不扩展每个节点的细节和功能、规则的话，简单的概述一个服务平台的业务就是：

服务单 - > 服务平台 - > 认证方 -> 被服务方 -> 被服务方的用户

这么一个流程线，然后因为服务平台天生具有的多变和稳定性。

所以在每个节点都需要操作者亲手通过，审核，并且留下历史操作记录，多变则体现在商城可以根据自己的商城需求自由的变动各个节点的审核顺序。

服务平台的业务全节点都联系着服务号下的各个服务单，所以在数据结构设计时。服务平台的驱动业务字段一定要能承接住全节点的使用需求。

比如被服务方接受认证方的数据节点，则需要服务单中的 [认证方，认证标识]字段

或者说每个审核节点需要的审核字段等...

随着节点数目的增加，服务单的压力就越大。

当然可以选择分表，水平或是垂直，但是这样的弊端也很明显。

但需要展示历史服务单或者我的服务单这样的“全量”查询功能时，随着分表的增加，字段确实少了，但是需要联表查询的数目随着分表的增加而增加。

所以对这个业务驱动节点的结构设计是非常非常重要的一环😠

业务扩展

服务平台属于一种万金油的系统平台，所以单个业务很容易被另一个业务所接受。

比如，还是上面的营销服务平台，当UC用户系统插入时，可以轻松的嵌套。

营销服务-> 用户校验、查询、管理

这样

还比如财务模块介入时，只需要在节点上多开一个特殊节点。

还是以服务单号进行财务模块的驱动，进行服务单的收付款操作。

所以的节点操作记录也还是可以保存在同一张服务单历史记录单中。

所以服务平台的业务扩展没有 展示平台、管理系统、甲方平台 等等那么的复杂

但是一切的一切还是归咎于需要一个强大的服务单结构设计。

总结

首先说好，以上纯属个人理解，不带任何第三方因素影响。

加上自己开发的分支模块：财务模块，开发过程的理解。