前言
先做一下自我介绍，我是数字供应链事业部下面业财一体部门的一名后端开发。
目前负责的一个工作是升级改造付款执行组件。所谓付款执行就是将我们结算域计算出来的，应该给供应商结算的钱，打给供应商。简单的说就是设计一个打款中台。
因为一些历史原因，我们结算域有四套付款执行代码，分布在四个不同的系统中。因此经常一个功能在一个版本上线之后，另一个版本的付款执行想用得重新写一遍，因此功能复用性比较差，组件维护也比较复杂，得看四套代码才能把域内的付款执行hold起来。
运维了一段时间的付款执行组件，我经常会思考：业务中台到底要沉淀什么样的能力？
思考
作为业务中台，需求方太多了，跟着需求走的话完全没法收敛，但人力又是有限的，怎么样用有限的人力去维护无限的需求。
想要需求收敛，首先得版本归一。版本如果不归一，某一个版本的组件写的再好也没有用，因为需求方的链路不走你这个组件就没有任何复用性。但是版本归一是一个长期的，各个域联动归一的过程，事情太大，问题太多这里就不展开了。这里说说我们能做的，我们能做的就是写好自己的组件，等哪一天要归一时，你的组件拥有最强的兼容性，是最好的归一方。
这个兼容性就要求对业务流程有一个标准的抽象，使所有相关的业务都能在这个标准流程里面跑下去。
抽象出这个标准流程之后，就进入了实施层面。作为业务中台，需求肯定会很多，我们要尽量避免自己成为单点故障。因此系统设计时要让系统可扩展性强。这个可扩展性侧重点应该是扩展简单，能让一些不了解你系统的人，能够以较低的成本来参与到你系统的共建。同时你还得能对你的系统有一个比较强的品控，不要因为多人参与共建让你的系统代码迅速的腐化。
这么说可能太官方，举个生活中的例子吧。我不太会做饭，我老婆比较会做。一开始我老婆做饭，我等着饭菜端上桌。时间久了，她不乐意了，都是九年义务教育出来的，凭什么你这么秀。于是她开始慢慢的将一些洗菜、切菜、洗碗，这种是个人就能做的工作外包给我。渐渐的她又将一些焯水，油爆这些不会影响菜的口感的工作外包给我。她专注炒菜的流程，食材的放入顺序，调料的用量，火候的掌控。这样我们两个人都有了清晰的分工，同时又不影响菜品的质量，而且也减少了家庭矛盾。
我觉得这个过程是中台演进的一种思路，软件的协作方式其实跟人的协作方式是相通的。作为一个业务中台，我们应该沉淀的就是食材的放入顺序，调料的用量，火候的掌控，这些做好了一道菜的品质就不会有大的问题。像洗菜、切菜、洗碗、焯水、油爆这些工作，定好标准，外包出去就好。
设计
付款执行系统整体设计
上图是我的付款执行系统的整体设计，可以看到此系统通过hsf接收付款单，通过系统的一通处理，把钱正确的付出去。然后将付款单状态变更发到消息中间件，关心付款单状态变更的系统订阅相应的topic。这样整个付款系统与其它系统完全解耦。
可以看出，此系统开放了四个spi：
1、查询打款账户spi 3、打款渠道spi
2、打款批次生成spi 4、打款控制spi
这四个spi解决了给谁打钱，以什么聚合方式打钱，用什么渠道打钱，控制哪些单子不打
这个是付款组件里面会变的东西，因此将其以spi的方式将其扩展出去，可外包给行业特种兵实现，达到共建的目的。而且这些spi由我定义好入参出参，特种兵可根据我定义的标准去实现接口，沉淀能力的同时，不会对我的整体流程造成冲击。
付款执行流程
提交打款
打款结果处理
如上图，红色的节点是我开放出去的能力，蓝色的节点是我重点沉淀的流程逻辑。行业特种兵根据自身行业特性，实现红色节点部分即可非常简单的接入付款执行系统。其只需要根据我给的入参，经过自己的逻辑处理给出我需要的出参即可。落库，重试，可靠系保证，安全性保证全由我的流程逻辑保证。
因此我可以慢慢沉淀我的流程逻辑，使其可靠，稳健，同时作为一个字段提供商，提供特种兵实现spi时需要的一些入参。这样我的需求就是可收敛的，付款接入需求陡增时，我可以把开发任务分发出去，有可复用的bundle直接复用，有特殊需求的，也可以把bundle转给其他人并行实行。
