系列文章：
一、前言
通过前四篇文章的介绍，我们落地一套基于TMF思想的扩展点框架，该框架的最大优势是实现了通用逻辑和扩展逻辑的分离，同时保证了系统的稳定性和扩展性。由于框架本身存在一定复杂性，因此也需要根据业务场景决定是否真的需要引入。
二、框架适用场景
由于框架涉及众多概念，理解成本会比较高，因此对于大部分简单项目用一些设计模式即可解决扩展性问题。该框架较适用于复杂场景，多接入方，接入方有较多的扩展性诉求 (例如一些中台系统)。
对于拥有众多业务方的交易系统，采用该框架较为合适
三、框架可能带来的问题
问题1: 扩展点怎么定义 ？
系统哪些功能需要定义成扩展点呢，抽象的原则是什么呢 ？一般来讲扩展点和业务息息相关，扩展点可以随着业务发展不断的沉淀出 (当多个业务都有扩展诉求时，就可以抽象出扩展点)。扩展点也可以由产品经理提前作为功能点进行提前规划。
问题2: 扩展点的扩展粒度怎么定义 ？
如果扩展点定义的过多，或者扩展点的参数过于灵活，那将可能导致逻辑泄漏到业务方，给业务方带来较大的维护负担。因此需要遵循一些基本的原则：
- 通用逻辑优先原则 (能抽象成通用流程尽量抽象成通用流程，扩展点核心是解决扩展问题)
- 入参最小满足原则 (参数尽量仅满足当前扩展需求就行，后续不够可以再加，如无必要勿增实体)
- 返回值简单清晰原则 (扩展点的返回值定义尽量简单清晰，如能用枚举尽量用枚举，减小实现方负担)
问题2: 业务实现有bug影响整个系统稳定怎么办 ？
由于系统会加载所有业务方的扩展点实现，如果实现有bug(例如cpu跑满)，业务方的代码质量直接影响平台稳定性，因此在加载前测试必须严格，对于核心业务也可以独立集群部署，避免其他业务影响。
四、框架可能的迭代方向
- 业务和能力的热加载，支持自定义classloader动态加载业务方的扩展点实现，这样中台的发布节奏就可以和业务方分离，业务方可以自闭环开发上线节奏。
- 建设管理后台，便于管理中台扩展点，能力和业务。
五、小结
至此本系列文章分享告一段落，关于交易中台系统一些其他的设计后续也会出一些其它系列文章进行分享。
