对于多系统对接，我们除了要信息及业务连通之外，更需要注意科学合理性

刀影

一分自信一分成功，十分自信，十分成功。

2019-03-13

对于多系统对接，我们除了要信息及业务连通之外，更需要注意科学合理性。

一、需求描述

公司在做的车抵贷业务，需要引入一家新的资金机构，我们称之为Z机构。它与目前所接入的资金机构所不同的是，Z机构对抵押车的借款成数有限制。比如：某车的评估价为10万，公司核批的最大借款金额为8成，也就是8万，但Z机构的最大批核成数却只有7.5成。最终使得公司核批的成数无法适用于所有机构。

为了尽可能地满足客户对资金的需求，解决Z公司的借款成数问题，公司决定引入信贷产品，用于补偿这个价差。

针对Z机构的成数限制问题，需要考虑具体的实现方案。公司的车贷和信贷产品是独立运营的，要实现车贷和信贷的组合借款，则需要在这两个系统间进行业务衔接和数据对接。

主要有如下几点：

车贷系统根据匹配的资金机构进行处理，当匹配为Z机构时，则判断用户借款金额是否超出了成数限制。如是，则自动降低借款金额，并记录下相关数据，以便提供给信贷系统。
考虑到组合借款业务逻辑的生效，是需要在车贷订单放款之后，因此建议由财务系统放款后，通知信贷系统进行相关业务处理。
信贷系统目前有白名单机制。白名单用户可直接绕过用户授信额度评估环节，直接分配一定的额度用于快速借款。有了这个基础，针对组合借款需求，则可以通过系统改造，根据给定的规则实现白名单的自动生成，最终完成用户信贷部分借款的顺利达成。

根据以上的分析，可以画出初步的流程图（核心流程）。

如下图所示：

系统间交互的几个关键点如下：

顺着思路再走一遍，也没发现什么问题，流程是通的，可以实现本需求。

流程是通的，但不代表是合理的。

对于多系统对接，我们除了要信息及业务连通之外，更需要注意科学合理性。因为多个系统，通常会涉及到多个开发团队。面对系统对接，我们除了要实现当下需求之外，还要尽可能地考虑后后续的需求扩展及功能维护。否则，随着时间的推移，系统交互会变得越来越混乱，最终变得不可维护。

根据我所总结的系统对接原则，我们进一步来审视分析这个流程。

原则一：尽量简单，避免因信息传递而失真。

在车贷系统调用财务系统接口时，增加了信贷授信额度参数。对于这个参数，显示是需要通过财务系统最终传递到信贷系统的。这很明显是属于数据传递，而这也是需要避免的。因为信号在传过程中不可避免地会产生衰减问题，而层层传递则会加大这种可能性。为此，我们需要避免这种做法。

那可以不传这个参数吗？完全可以。在第3步时，信贷系统在调用车贷接口获取信息时，完全可以直接通过这个接口可以拿到这个信息。

原则二：保持稳定，尽量避免基础业务接口的频繁调整。

同样还是针对上述对接——放款申请接口，这是作为借款服务最基本的业务接口，需要尽量保持稳定可用，避免因需求的跌代而产生不必要的扩展及调整。从这个角度来看，原本要增加的信贷授信额度等参数也是要避免的。而通过上面的分析已经有解决的方法，这里不再赘述。

原则三：考虑通用性，不要只解决当下需求。

财务系统判断为Z机构时，调用信贷系统接口通知其生成白名单，此为新增接口。但其实在财务系统放款后原本就会发出一MQ消息，通知各系统订单放款这一消息。而这一消息，信贷系统同样可以监听并消费。如果是通过放款MQ消息来实现与信贷系统的业务对接，那么这一过程就变得更为通用了。

同时，让财务系统作判断来决定是否通知信贷系统，从通用性上考虑，这也是不合理的。因为如果后续不只是Z机构，还有别的机构也同样有此需求呢？是否让财务系统再作一次调整？另外，从业务职责上考虑也不应由财务系统来实现这个逻辑。

综上分析，从通用性上考虑，采用现有的放款MQ消息实现系统对接，同时在MQ中增加资金机构信息，便于信贷系统作业务逻辑预处理。

原则四：独立自主性，内部业务逻辑不应由外部系统控制。

针对原本让财务系统作出判断来决定是否通知信贷系统生成白名单的逻辑，在这个原则下也是不合适的。因为生成白名单逻辑，是信贷系统的自有的内部业务逻辑，是不应该由外部系统来决定的。相对独立的业务系统对内部逻辑应该要有绝对的自主性。

因此，对于后续要扩展新的机构实现此类需求或是要关闭这个功能时，则应由信贷系统来负责管控，如设计一配置功能，实现业务的开关及增减。

通过这样的分析和调整最终我们发现，原本挺特殊的需求，在系统对接实现层面竟然也可以做到如此简单和通用。复杂的核心业务逻辑都被锁定在各系统内部，而系统对接部分则基本可以保持稳定和简单。

最后，我们把调整后的业务流程图画下来：

作者：星思维，微信公众号：成长星思维

本文由 @星思维原创发布于人人都是产品经理。未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议