架构设计方法 – 扩展性

什么是软件架构h2>

1. 软件架构这项工作的实质就是规划如何将系统切分成组件，并安排好组件之间的排列关系，以及组件之间互相通信的方式。
2. 软件架构设计的目标是支撑软件系统的全生命周期，设计良好的架构可以让系统便于理解、易于修改、方便维护，并且能轻松部署。
3. 软件架构的终极目标就是最大化程序员的生产力，同时最小化系统的总运营成本。
4. 软件架构设计关注产品的功能属性和质量属性，质量属性包括：扩展性、性能、安全性、可维护性、稳定性。

方法总结

1. SOLID 设计原则：单一职责、依赖反转、开闭、里式替换、接口隔离
2. 再往上是更大组件粒度的设计原则：复用/发布等同原则、共同闭包原则、共同复用原则、无依赖环原则、稳定依赖原则、稳定抽象原则
3. 再往上是服务级别的设计原则：划分边界
4. 常见的架构设计方法：整洁架构、端口与适配器架构、六边形架构

SOLID 设计原则

1. SRP 单一职责原则
   • 任何一个软件模块都应该有且仅有一个被修改的原因。
   • 任何一个软件模块都应该只对一类行为者负责。
   • 软件模块是指一组紧密相关的函数和数据结构。
   • 单一职责原则主要讨论的是函数和类之间的关系，但是它在其他讨论层面会以不同的形式出现。在组件层面，我们可以将其称为共同闭包原则，在软件架构层面，它则是用于奠定架构边界的变更轴心。
2. OCP 开闭原则
   • 设计良好的计算机软件应该易于扩展，同时抗拒修改。换个方式说，应该在不需要修改的前提下，就可以轻易被扩展。
   • 主要目标是让系统易于扩展，同时限制每次被修改所影响的范围。
   • 实现方式是将系统划分为一系列组件，并且将这些组件间的依赖关系按层次结构进行组织，使得高阶组件不会因低阶组件被修改而受到影响。
3. LSP 里氏替换原则
   • 如果每个类型是 S 的对象 o1 都存在一个类型为 T 的对象 o2，能使操作 T 类型的程序 P 在用 o2 替换 o1 时行为保持不变，我们就可以将 S 称为 T 的子类型。
4. ISP 接口隔离原则
   • 任何层次的软件设计如果依赖于不需要的东西，都会是有害的。从源代码层次来说，这样的依赖关系会导致不必要的重新编译和重新部署。
5. DIP 依赖反转原则
   • 如果想要设计一个灵活的系统，在源代码层次的依赖关系中就应该多引用抽象类型，而非具体实现。
   • 我们每次修改抽象接口的时候，一定也会去修改对应的实现。但反过来，当我们修改具体实现时，却很少需要去修改相应的抽象接口。所以可以认为接口比实现更稳定，应该在代码中多使用抽象接口，尽量避免使用那些多变的具体实现类。
   • 不要在具体实现类上创建衍生类。
   • 不要覆盖包含具体实现的函数。
   • 源代码依赖方向永远是控制流方向的反转，这就是 DIP 被称为依赖反转原则的原因。

组件构建原则

如果说 SOLID 原则是用于指导我们如何将砖块砌成墙与房间的，那么组件构建原则就是用来指导我们如何将这些房间组合成房子的。

组件聚合三原则：

1. REP 复用/发布等同原则
   • 软件复用的最小粒度应等同于其发布的最小粒度。
2. CCP 共同闭包原则
   • 我们应该将那些会同时修改，并且为相同目的而修改的类放到同一个组件中，而将不会同时修改，并且不会为了相同目的而修改的那些类放到不同的组件中。
   • 正如 SRP 原则提到的：一个类不应该同时存在着多个变更原因。CCP 认为一个组件不应该同时存在着多个变更原因。
3. CRP 共同复用原则
   • 不要强迫一个用户依赖他们不需要的东西。
   • 该原则建议我们将经常共同复用的类和模块放在同一个组件中。反过来说，不是紧密相连的类不应该被放在同一个组件里。
   • CRP 是 ISP 原则的一个普适版。ISP 建议不要依赖带有不需要的函数的类，CRP 建议不要依赖带有不需要的类的组件。
4. REP、CCP 是粘合性原则，他们会让组件变大。CRP 是排除性原则，会让组件变小。软件架构的任务就是在这三个原则中间进行取舍。

组件耦合三原则：

1. ADP 无依赖环原则
   • 组件依赖关系图中不应该出现环。
   • 组件结构图是不可能自上而下设计出来的，它必须随着软件系统的变化而变化和扩张，而不可能在系统构建之初就被完美设计出来。
2. SDP 稳定依赖原则
   • 依赖关系必须要指向更稳定的方向。
3. SAP 稳定抽象原则
   • 一个组件的抽象化程度应该与其稳定性保持一致。
   • SAP 为组件的稳定性和抽象化程度建立了一种关联。一方面该原则要求稳定的组件同时是抽象的，这样它的稳定性就不会影响到扩展性；另一方面该原则也要求一个不稳定的组件应该包含具体的实现代码，这样它的不稳定性就可以通过具体的代码被轻易修改。
4. 将 SAP 和 SDP 两个原则结合起来，就等于组件层次上的 DIP。因为 SDP 要求的是让依赖关系指向更稳定的方向，而 SAP 则告诉我们稳定性本身就隐含了对抽象化的要求，即依赖关系应该指向更抽象的方向。