可扩展性
可扩展性指系统为了应对将来需求变化而提供的一种扩展能力，当有新的需求出现时，系统不需要或者仅需要少量修改就可以支持，无须整个系统重构或者重建
- 在软件开发领域，面向对象思想的提出，就是为了解决可扩展性带来的问题
- 设计模式，将可扩展性做到了极致
- 设计具备良好可扩展性的系统，有两个基本条件：
- 正确预测变化
- 完美封装变化
预测变化
- 软件系统在发布后还可以不断地修改和演进，这就意味着不断有新的需求需要实现
- 如果新需求能够不改代码甚至少改代码就可以实现，皆大欢喜，否则来一个需求就要求系统大改一次，成本会非常高
- “唯一不变的是变化”，架构师每个设计方案都要考虑可扩展性
- 如果每个点都考虑可扩展性，架构师会不堪重负，架构设计也会异常庞大且最终无法落地
- 但架构师也不能完全不做预测，否则可能系统刚上线，马上来新的需求就需要重构，这同样意味着前期很多投入的工作量也白费了
- 预测变化的复杂性在于：
- 不能每个设计点都考虑可扩展性
- 不能完全不考虑可扩展性
- 所有的预测都存在出错的可能性
- 对于架构师来说，如何把握预测的程度和提升预测结果的准确性，是一件很复杂的事情，而且没有通用的标准可以简单套上去
应对变化
- 假设架构师经验非常丰富，目光非常敏锐，看问题非常准，所有的变化都能准确预测，是否意味着可扩展性就很容易实现了呢？
- 也没那么理想！因为预测变化是一回事，采取什么方案来应对变化，又是另外一个复杂的事情
- 即使预测很准确，如果方案不合适，则系统扩展一样很麻烦
- 第一种应对变化的常见方案是将“变化”封装在一个“变化层”，将不变的部分封装在一个独立的“稳定层”
变化设计层次
-
无论是变化层依赖稳定层，还是稳定层依赖变化层都是可以的，需要根据具体业务情况来设计
- 如果系统需要支持 XML、JSON、ProtocolBuffer 三种接入方式，那么最终的架构就是上面图中的“形式 1”架构，也就是下面这样
接入层变化- 如果系统需要支持 MySQL、Oracle、DB2 数据库存储，那么最终的架构就变成了“形式 2”的架构了，你可以看下面这张图
数据层变化 -
无论采取哪种形式，通过剥离变化层和稳定层的方式应对变化，都会带来两个主要的复杂性相关的问题
- 系统需要拆分出变化层和稳定层
- 需要设计变化层和稳定层之间的接口
-
第二种常见的应对变化的方案是提炼出一个“抽象层”和一个“实现层”
- 抽象层是稳定的，实现层可以根据具体业务需要定制开发，当加入新的功能时，只需要增加新的实现，无须修改抽象层
- 典型的实践就是设计模式和规则引擎
