一个疑问
为了能够让程序可以扩展，在后续的中台化讨论中我们会发现会抽取出一个SPI(程序的可扩展接口，不同的项目可以扩展实现接口，满足自己的个性逻辑)；语言本身，比如java，本来就提供了interface和子类可以overwite父类的方法，提供了很强的扩展能力，为什么我们还要做专门的SPI抽取呢？这是个好问题，值得我们深思。
什么都行很多时候等于什么都不行
先看下java语言实现的框架（你可以想象成我们使用的spring或ibatis等你常用的java开源框架），我们大部分时候都是直接使用，但我们现在讨论的是二次开发支持问题，先看下下面的图：
如果我们大量扩展了框架，框架升级的时候很难保证所有的接口和类不发生改变，发生升级后，我们会发现我们的扩展开发都无法正确运行了；如果是少量的二次开发，这个调整可以接受；但对于一个面对二次开发需求的框架来说是不可接受的。
减少承诺，遵守承诺
为了能更好的保护扩展开发的业务资产，我们应该减少可扩展的范围，并尽量保证这些可扩展的地方不变性。减少承诺，你才能更好的实现承诺。
第一步：框架分离开可以扩展部分和不可扩展部分，不可扩展部分伴随框架升级可以随便修改，可扩展部分尽量提供历史兼容；在第三方开发可稳定扩展和框架本身的可持续升级之间取得平衡；
第二步：框架可扩展部分的接口第三方可以扩展，理论上实现了这些接口的官方组件客户端可以直接使用或写子类overwite掉；但这样会强化官方组件的承诺，我们以后升级官方组件，还要考虑客户端的overwite情况，这条线也可以砍掉。
通过上面两步，我们得到了下图：
总结
本篇为【中台化建设】的引导篇，接下来可以阅读【中台化建设】，里面应该可以看到扩展性折中的影子。
扩展性和限制扩展性的范围需要折中思考，和项目的背景有很大关系； 如果你项目本身就是标准指定者，那么显然扩展点就算多点也没关系，因为第三方本来就要遵从标准，升级标准对第三方造成的改变是必然的；反之如果你不是标准制定者，那可能需要好好权衡了。