《架构整洁之道》阅读笔记

一、背景

　　在整理现有负责的系统结构时候，总是感觉有些不协调感，但又说不上来，大家都用的相同的约定，熟悉的框架和结构，底层组件也管理的十分规整有序，但系统给人的“嘈杂”感觉始终无法消除，无意中发现自己买来就一直在吃灰的《架构整洁之道》，决定苦修一下基本功，好好研读一下。

二、阅读概览

1、整理这本书的目录结构

 　　通读整本书，虽然书里已经将目录分解成了五个章，但我从一个开发者的角度分析，我觉得可以分层以上三个层次。

第一个层次是书里最靠前也最底层的是我们研发所要共同遵循的范式和设计原则，这些基础中的基础，就类似于数据库的元数据一样，是大家都要遵守的东西，不会多也不会少。

第二个层次是架构设计所需要注意的东西，也就是本书中间部分，着重阐述的各种观点和分类；

第三个层次则是与架构设计不可分割的最细粒度---实现部分，这部分大都是作者轻描淡写的概述，但也清晰的阐述了设计细节如何影响系统架构；

2、梳理书中的原则与约定

• 软件架构责任的基本原则：

　　（1）平衡系统架构的重要性与功能的紧急程度，是软件研发人员自己的职责。

　　（2）软件架构的终极目标是，用最小的人力成本来满足构建和维护该系统的需求。

　　（3）软件架构师的基本职责是必须创造出一个可以让功能实现起来更容易、修改起来更简单、扩展起来更轻松的软件架构。 

• 软件设计原则

　　（1）SRP-单一职责原则

　　　　描述：任何一个软件模块都应该只对某一类行为者负责。（结合康威定律：软件模块或功能应该忠实服务于某一特定组织或节点）

　　　　书中小结：单一职责原则主要讨论的是函数与类之间的关系---但是它在两个讨论层面上会以不同的形式出现：

　　　　　　　　　　在组件层面，我们可以将其成为共同闭包原则 （Common Closure Principle）；

　　　　　　　　　　在软件架构层面，它则是用于奠定架构边界的变更轴心（Axis of Change）；

　　（2）LSP-里氏替换原则

　　　　描述：书中没有具体的原则描述，但可以理解为衍生子类的实现对象，可以替换父类的实现对象，而使任何程序的行为都不用依赖任意衍生类；

　　　　书中结论： LSP在普遍认知中是指导如何使用继承关系的一种方法，然而随着时间推移，逐渐演变成一种更广泛的、指导接口与其实现方式的设计原则；一但违背了可替换性，该系统架构就不得不为此新增大量复杂的应对机制；　　　　　　　　　　　　　

　　（3）OCP-开闭原则

　　　　描述：设计良好的计算机软件应该易于扩展，同时抗拒修改（或者说，通过扩展来代替修改）；

　　　　书中小结：OCP是我们进行系统架构设计的主导原则，其主要目标是让系统易于扩展，同时限制其每次被修改所影响的范围。（通过将系统划分为一系列组件，组件间的依赖关系按层次结构进行组织，使高层次组件不会因低层次组件被修改而受到影响）

　　（4）ISP-接口隔离原则 

　　　　　描述：在设计时尽可能的分离掉不需要的实现依赖。因为在一般情况下，任何层次的软件设计如果依赖于不需要的东西，都会是有害的。这也是这一章节的小结。（每次组件新特性上线都要对应于一个新的API版本和新的接口，这会导致依赖膨胀）

　　　　

 

　　　（5）DIP-依赖反转原则  

　　　　　　描述：如果想要设计一个灵活的系统，在源代码层次的依赖关系中就应该多引用抽象类型，而非具体实现；所以优秀的软件设计师和架构师会花费很大精力来设计接口，以减少未来对其改动。在系统架构图中，DIP是最显而易见的组织原则；（可以这样理解：系统或模块的抽象程度决定了它的设计灵活性，但没有边界的灵活性就是种维护上的灾难）

 

• 组件构建原则

　　　（1）组件都是该软件在部署过程中的最小单元。

　　　（2）组件聚合三原则（构成组件的设计原则）

• • REP-复用/发布等同原则

　　　　　　书中的定义：软件复用的最小粒度应等同于其发布的最小粒度。

　　　　　　这个定义再约束两类问题：1、组件的类与模块应该聚合到可以同时发布的粒度，这也意味着他们共享相同的版本号与版本追踪；2、一个组件不能包含毫不相干的类与模块。

                   但书中也提到这个规则的薄弱点是没有清晰地定义出到底应该如何将类与模块组合成组件；也就是说组件内的关系与层次的管理并不在这个定义的范畴。

• • CCP-共同闭包原则
  • CRP-共同复用原则

　　　（3）组件耦合三原则（组件依赖关系管理的原则）

　　　　　　ADP-无依赖环原则

　　　　　　SDP-稳定依赖原则

　　　　　　SAP-稳定抽象原则

 

3、组件与架构中的注意事项

　　（1）独立性与划分边界

　　（2）业务逻辑与整洁架构

　　（3）层次划分与服务

　　（4）Main组件

　　（5）测试与嵌入式

4、实现与架构的关系和注意事项

 　　（1）实现细节污染架构

　　 （2）聚焦在核心业务逻辑的设计而非“外貌”

　　 （3）应用框架不等同于系统架构

5、读后感