从0到1做一个“保证金”系统
我想大家对保证金都不陌生，从最早的淘宝开店要缴纳店铺保证金，然后的共享单车要缴纳骑车押金。
这也是平台为了增加商家、用户的信用等级或者风险兜底，而向收取的一笔担保资金。
车坏啦、商家被投诉啦，这笔钱就排上用场了。
一、定种类，设规则
平台一般会基于不同场景，缴纳不同类型的保证金，这就是保证金的种类。
所以在设计保证金系统之前先了解清楚贵司的保证金种类以及拓展性。
1. 定种类
比如内容分销保证金，是基于分销市场场景而设立的，主要是为了提高分销商的信用担保。
再比如店铺保证金，是为需要开店的商家设立的，为提高店铺的信用，兜底平台和用户的基本权益
因此，不同的业务种类或者普通的场景需要设定不同类型的保证金。
就需要一个“保证金类型”管理，来不断地拓展保证金类型。
2. 立规则
有了保证金类型以后，接下来就是保证金的缴纳规则，也就是制定一份规范。
谁，在什么时候，什么地方，做什么事，要缴什么保证金，缴多少钱。
比如可能不同的城市消费水平不同，那么缴纳的金额可能就不一样。
不同的城市可能不一样，比如同样是跑滴滴，在一线城市缴纳的保证金和一个五线城市就可能不一样。
不同的服务品类可能不一样，比如同样是在一线城市，跑快车和跑专车要缴纳的保证金金额不一样。
比如下图是某电商平台针对不同品类及商家主体类型设定了不同金额的保证金。
为了通过系统化实现上述保证金的充值、缴纳、管理等一系列业务，就需要一个保证金系统。
接下来，我们从业务框架、产品架构、具体模块设计展开对该系统的设计分析。
二、三个架构看全局
要先搞明白，我们做这个系统要实现哪些业务种类和对外能力。
系统没开始，业务先想明白，业务想明白了，系统也就清晰了。
1. 关系架构
第1个架构是关系架构，我们看清楚整个系统与外界“基于服务”的联系，谁会通过什么服务来与我建立关系，我就明白了，我要做这些能力。
从图中可以看出，保证金需要依赖商家中心的通知进行开户，然后基于自己的规则告知商家需要缴纳什么保证金，缴多少钱，以及后续的业务发生后对保证金缴纳情况的检验查询、违规扣除、风控冻结、审批等一系列的业务关联。
2. 业务架构
第2个是业务架构，通过这个架构看清楚保证金系统与各系统之间更清晰的业务关系。
从图中可以更清晰的看出来，保证金的什么服务模块为哪些上下游系统提供什么样的服务，比如为钱包提供查询服务、为支付系统提供交易服务、为商家中心及风控系统提供基础服务，而自己的所有服务都是基于保证金规则和账户为基础。
3. 产品架构
第3个架构就是产品架构，看清楚保证金系统的所有功能模块，便于后面的详细产品设计和项目落地。
整个保证金划分为5大模块，分别是保证金服务管理、保证金规则管理、保证金交易能力管理、保证金账户管理、保证金操作记录。
这里要特别说明的是保证金账户管理，如果说保证金账户由账户中心承接，那么这一部分就应该是“保证金账务处理”的管理，与账户中心形成交互，而保证金系统就成了一个单纯的业务系统，管理保证金业务相关的事务。
三、五大模块定乾坤
接下来就应该针对上述的每一个模块做详细的产品设计。
1. 服务标准化
对于保证金服务模块其实就是抽象出的服务种类，以标准接口的形式提供给外界系统调用。
例如开户、销户就是来申请开通保证金账户，并匹配对应的规则，知道这个账户需要缴纳多少金额的保证金。
交易服务就是充值、提现、扣除、解冻、冻结保证金的能力，这是保证金能力的核心所在，毕竟有了保证金你是要辅助业务做事情的，去兜底的。
状态查询是保证金是否已缴纳的查询，提供给业务侧做业务的判断，比如商家要上架商品时，需要判断有没有缴纳足额保证金，以控制商家能不能正常上架商品。
账户查询是提供给钱包使用，获取保证金的账户余额、流水数据。
报表服务是提供给财务使用，用于保证金业务的会计记账。
2. 规则配置化
保证金规则，关键是规则模型。
前面也介绍了，不同的业务及场景需要缴纳的保证金种类和保证金金额不同，所以需要一套规则配置工具，灵活的配置出保证金的规则条目。
这里将规则引擎设置成2层模式：
第一层是规则模版层，是为每一个保证金场景，设置一个规则模版，也就是这个场景下的保证金规则需要哪些维度的参与决定。
比如条目1的含义就是分销保证金的规则只需要配置一个参数即可，也就是品类，不同的品类保证金规则不同。
所以，一个条目能配置出多少条规则，跟该条目的参数数量以及每个参数的枚举值有关系。
所以需要一个定义“参数”的配置，例如增加商品、用户等级、时间等各类参数，这里就不赘述了。
在新增条目时，可以为每一类保证金类型增加一个条目，为该条目选择需要配置的参数。
有了条目以后就是为各类保证金场景设置规则了。
比如店铺保证金的条目是002，那么设置店铺保证金规则时就需要配置“业务线、品类、城市”3个维度的元素，他们不同保证金规则不同。
3. 交易能力按需化
这里的能力就是交易的能力，充值、提现、冻结解冻、扣除等操作保证金账户的能力。
这个能力都可以做成标准化的交易能力，当然可以基于实际需要去建设，比如冻结能力，如果没有冻结场景，那就不需要去建设。
这里特别说明一下，保证金的冻结和解冻可以做成自动化的任务，在约定好冻结和解冻的条件，定期巡检全部保证金账户，然后执行冻结或者自动解冻。
4. 账户管理可选择
这是保证金的核心，前面也说了，可以保证金系统自己管理，也可以交付给账户中心承接，不同的模式下，保证金的账户管理要做的事情不同。
如果是保证金自己管理自己的账户，那么就需要做一个基础的账户模块，有余额、流水、开户销户、出入账等相应的能力。
5. 操作记录不可抵赖
最后就是保证金的操作记录，这里的操作记录更详一个保证金系统的日志，记录的谁、在什么时候、对系统里的那个模块做了什么。
好了，以上就是保证金系统的建设方法论，如何从0到1把这个系统做出来，你学会了么。
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
