考虑通用性，不要只解决当下需求

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

1. 车贷系统在完成组合逻辑运算后，将调用已有财务系统的申请放款接口，同时增加信贷授信额度等关键传参给到财务系统；
2. 财务系统判断当前订单的资金机构为Z机构时，调用信贷接口传入信贷额度等参数，通知其启动白名单生成逻辑；
3. 信贷系统根据请求，进一步调用车贷接口获取完整的所需信息后生成相应的白名单。

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

四、对接复盘

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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