系列文章：
一、如何解决中台扩展性问题 ？
随着业务的功能不断增加，系统一般都会不断腐化，其过程可参考前一篇文章。从一些公开的文章中，可以看到淘宝的交易平台TMF框架在解决扩展性问题，有一套较为优雅和完备的方案。碍于框架未开源，本系列文章计划参考TMF的核心设计思想，落地相应的扩展点框架的实现。
二、扩展点插件化设计
TMF框架核心提出了中台逻辑和业务逻辑分离的原则，中台只包含通用流程，差异逻辑下放到业务方实现，可以达到中台和业务逻辑解耦效果，大大提高了系统的扩展性。
扩展点即中台定义的接口，接口的实现交由业务方实现。这里以下单过程中，提供的算价扩展点为例，伪代码实现如下，后续将逐步深入讲解。
@RestController
@RequestMapping("/api")
public class CreateOrderController { // 中台下单通用流程
// 通用流程提供了算价扩展点
// 期望根据不同业务注入不同的实现 (如何动态注入?)
@Autowired
CalculatePriceExtension calculatePriceExtension;
@PostMapping("/create_order")
public OrderDTO CreateOrder(CreateOrderDTO dto) {
// 其它创单逻辑 ......
// 根据不同的业务，动态调用业务定制化实现 （省略其它逻辑）
Integer price = calculatePriceExtension.calcPrice();
// 创单
OrderDTO order = new OrderDTO();
order.price = price;
return order;
}
}
// 扩展点定义
interface CalculatePriceExtension {
Integer calcPrice();
}
三、TMF核心概念
从上述内容可以看出，业务就是实现了一组中台扩展点。在整个交易流程中业务需要一个唯一身份进行标识，以路由到不同业务的扩展点实现。
我们再思考两个问题，假如我是业务方，我想接入中台交易流程。
问题1: 我只想体验一下，不实现任何扩展点可以跑通吗 ？
问题2: 另外一个业务实现了一组扩展点，达成了特定的业务玩法功能，我也想借鉴一下，那需要copy他的扩展点实现代码，自己再重新实现一下吗 ？(比如一个行业实现了订金尾款，我也想实现该玩法)
第一个问题，当然可以跑通，中台会提供默认兜底实现。第二个问题其实是扩展点的实现有复用的诉求，我们称之为"能力"，为避免重复实现，中台提供一些标准的能力实现，业务只需要挂载，无需重复开发。
TMF有三个核心概念: 1.业务身份；2.业务；3.能力；下一篇文章将围绕这三个核心概念展开讨论，敬请期待后文讲解。
