完整的风控项目必定编译打包生成了一颗树（这个过程咱们先不分解，因为实际上咱们也可以看得到这棵树被完整的打包编译了出来）
上面的树指的是关系树，物理上依旧是各自独立的模块
api部分只需选定#一个#树节点进行依赖（看似蜻蜓点水，威力却巨大），依赖后，我们可以很容易的顺着依赖进入不属于API项目本身的部分
可以从实际的jar包中进入，也可以从版本库的pom文件中进入（实际都是在仓库里一层一层的进入）
所以，咱们这一蜻蜓点水，逻辑上只是点了一个树节点，物理上导入的依赖包却是节点下的整颗树
于是乎，在逻辑上也可以进行子树节点的调用，api也可以顺利编译了
虽然编译通过，但此时的api只是选定风控树的对外节点进行依赖的（其实就算你有整颗风控树，你也只能带动对外节点的子树），就像两个三角形他们只有边角的一部分进行了覆盖，那么对上面三角形的染色最多遮挡到另一个三角形的一部分，完美解耦合！！
这时项目能通过编译不错，但一定跑不起来，水往低处流，一旦流至叶子节点（风控对外接口），只能停止。
换句话说，我给你两个三角形边角依赖的项目，你从其中依赖方起项目，一定起不来。
一定要先起被依赖方，再起依赖方，当两个项目都起来时，web容器会起到导流的作用，当水流至最低点的接口时，被引流到了被依赖方的高处（bean的注入）
接下来两个项目组，协调，上线，版本迭代都没问题了哈哈
这时你发现，通过接口居然能使两个项目完完全全独立开发，接口的作用在多个项目中被不断放大，你是不是得换个更大的角度重新思考看待一下接口呢，之前接触的的设计模式是不是也可以重新理解一遍了呢