从0到1做一个“保证金”系统

一、定种类，设规则 

平台一般会基于不同场景，缴纳不同类型的保证金，这就是保证金的种类。 所以在设计保证金系统之前先了解清楚贵司的保证金种类以及拓展性。 

1. 定种类 

比如内容分销保证金，是基于分销市场场景而设立的，主要是为了提高分销商的信用担保。 再比如店铺保证金，是为需要开店的商家设立的，为提高店铺的信用，兜底平台和用户的基本权益 因此，不同的业务种类或者普通的场景需要设定不同类型的保证金。 就需要一个“保证金类型”管理，来不断地拓展保证金类型。 

如果您需要相关服务，可以找天津天迅达科技有限公司，我们的业务有Web开发、iOS APP、Android APP、微信开发、HTML5开发等，天迅达——您身边的App个性化定制专家！

2. 立规则 

有了保证金类型以后，接下来就是保证金的缴纳规则，也就是制定一份规范。 谁，在什么时候，什么地方，做什么事，要缴什么保证金，缴多少钱。 比如可能不同的城市消费水平不同，那么缴纳的金额可能就不一样。 不同的城市可能不一样，比如同样是跑滴滴，在一线城市缴纳的保证金和一个五线城市就可能不一样。

二、三个架构看全局 

要先搞明白，我们做这个系统要实现哪些业务种类和对外能力。 系统没开始，业务先想明白，业务想明白了，系统也就清晰了。 

1. 关系架构 

第1个架构是关系架构，我们看清楚整个系统与外界“基于服务”的联系，谁会通过什么服务来与我建立关系，我就明白了，我要做这些能力。 从图中可以看出，保证金需要依赖商家中心的通知进行开户，然后基于自己的规则告知商家需要缴纳什么保证金，缴多少钱，以及后续的业务发生后对保证金缴纳情况的检验查询、违规扣除、风控冻结、审批等一系列的业务关联。 

2. 业务架构

 第2个是业务架构，通过这个架构看清楚保证金系统与各系统之间更清晰的业务关系。 从图中可以更清晰的看出来，保证金的什么服务模块为哪些上下游系统提供什么样的服务，比如为钱包提供查询服务、为支付系统提供交易服务、为商家中心及风控系统提供基础服务，而自己的所有服务都是基于保证金规则和账户为基础。

 3. 产品架构 

第3个架构就是产品架构，看清楚保证金系统的所有功能模块，便于后面的详细产品设计和项目落地。 整个保证金划分为5大模块，分别是保证金服务管理、保证金规则管理、保证金交易能力管理、保证金账户管理、保证金操作记录。

 这里要特别说明的是保证金账户管理，如果说保证金账户由账户中心承接，那么这一部分就应该是“保证金账务处理”的管理，与账户中心形成交互，而保证金系统就成了一个单纯的业务系统，管理保证金业务相关的事务。

 三、五大模块定乾坤 接下来就应该针对上述的每一个模块做详细的产品设计。

 1. 服务标准化 对于保证金服务模块其实就是抽象出的服务种类，以标准接口的形式提供给外界系统调用。 例如开户、销户就是来申请开通保证金账户，并匹配对应的规则，知道这个账户需要缴纳多少金额的保证金。 

交易服务就是充值、提现、扣除、解冻、冻结保证金的能力，这是保证金能力的核心所在，毕竟有了保证金你是要辅助业务做事情的，去兜底的。 状态查询是保证金是否已缴纳的查询，提供给业务侧做业务的判断，比如商家要上架商品时，需要判断有没有缴纳足额保证金，以控制商家能不能正常上架商品。 账户查询是提供给钱包使用，获取保证金的账户余额、流水数据。 报表服务是提供给财务使用，用于保证金业务的会计记账。

 2. 规则配置化 保证金规则，关键是规则模型。 前面也介绍了，不同的业务及场景需要缴纳的保证金种类和保证金金额不同，所以需要一套规则配置工具，灵活的配置出保证金的规则条目。 

这里将规则引擎设置成2层模式： 第一层是规则模版层，是为每一个保证金场景，设置一个规则模版，也就是这个场景下的保证金规则需要哪些维度的参与决定。 比如条目1的含义就是分销保证金的规则只需要配置一个参数即可，也就是品类，不同的品类保证金规则不同。

 所以，一个条目能配置出多少条规则，跟该条目的参数数量以及每个参数的枚举值有关系。 所以需要一个定义“参数”的配置，例如增加商品、用户等级、时间等各类参数，这里就不赘述了。 在新增条目时，可以为每一类保证金类型增加一个条目，为该条目选择需要配置的参数。

以上所有设计图和部分文字均来自网络，如有侵权，请call我删除，感谢~

天津天迅达科技有限公司经过多年来对APP、小程序、以及网站建设的探索，已经帮助每一个客户快速开发出属于自己的APP、小程序、网站，是万千企业之选。

标签：天迅达科技 天津APP开发 天津网站建设 网站建设