系统架构设计整洁之道

1、 Page * MERGEFORMAT 14系统架构设计整洁之道目 录 TOC o 1-3 h z u HYPERLINK l _Toc44448598 一、架构设计的目标 PAGEREF _Toc44448598 h 3 HYPERLINK l _Toc44448599 二、软件系统的价值 PAGEREF _Toc44448599 h 3 HYPERLINK l _Toc44448600 三、编程范式 PAGEREF _Toc44448600 h 4 HYPERLINK l _Toc44448601 四、设计原则 PAGEREF _Toc44448601 h 5 HYPERLINK l _T

2、oc44448602 五、组件 PAGEREF _Toc44448602 h 7 HYPERLINK l _Toc44448603 六、封装方式 PAGEREF _Toc44448603 h 10 HYPERLINK l _Toc44448604 七、软件架构 PAGEREF _Toc44448604 h 10一、架构设计的目标用最少的人力成本满足构建和维护该系统的需求衡量指标工程师团队规模代码总行数代码变更行数二、软件系统的价值行为价值按需求文档编写代码可用性功能性bug性能稳定性紧急，但是并不总是重要架构价值当需求变更时，所需的软件变更必须简单方便变更实施的难度应该和变更的范畴（scope

3、）成等比，而与变更的具体形状（shape）无关不紧急三、编程范式目的：设置限制，告诉我们不可以做什么现有范式结构化编程目的：对控制权的直接转移进行了限制和规范内容：可以用顺序结构、分支结构、循环结构这三种结构构造出任何结构；限制goto的使用。意义：用代码把一些已证明的结构串联起来，就可以推导出整个程序的正确性。实际上没有办法证明每个程序段是正确的，只能证伪，如果所有的基本单元都无法证伪，那么整个就是无法证伪的，那目前就是正确的。延伸：物理学与数学的区别，物理学的基本公式都是没有办法证明的，只能证伪，所以物理学是实验科学，没有一个公式是完全靠得住的，只是目前靠得住。数学的基本公式都是可以证明的

4、。面向对象编程目的：对程序控制权的间接转移进行了限制和规范定义封装：只暴露部分函数，数据则完全不暴露继承多态：其实只是函数指针的一种应用，通过接口和实现，抽象类和继承，替代了函数指针的使用意义：函数指针，是跨越组件边界的方法，是组件独立部署的基础，依赖反转的基础。依赖反转指的是让依赖与控制流向相反。函数式编程目的：对赋值进行了限制和规范趋势：如果有足够大的存储量和计算量，应用程序可以用事件溯源的方式，用完全不可变的函数式编程，只通过事务记录，从头计算状态意义：所有的竞争问题、死锁问题、并发问题都是由可变变量导致的。应用：通过将状态修改的部分和不需要修改的部分分隔成单独的组件，提高系统的稳定性和

5、效率四、设计原则意义如何将数据和函数组织成类如何将类链接起来成为组件和程序开闭原则（OCP）目标：让系统易于扩展，同时限制每次修改所影响的范围实现：划分组件，并将组件间依赖关系按层次结构进行组织本原则是我们进行架构设计的主导原则单一职责原则（SRP）目标：指导类、组件拆分定义任何一个软件模块，都应该有且只有一个被修改的原因“被修改的原因”指系统的用户或所有者痛点同样的一块逻辑，如果服务于两个价值主体，因为一个价值主体而修改，那么第二个价值主体期望的功能将被影响。比如CTO和COO都要员工的工时，分别用于计算薪酬和汇报，两者的计算方式可能目前是相同的，一方有了更改，另一方就bug了如果一块代码，

6、归属于两个团队共同维护，就会有代码合并问题里氏替换原则（LSP）目标：指导接口与实现方式【边界处理】内容不是实现了同一个接口，它们的行为就是一致并可以互相替换，长方形正方形是典型的案例如果两个组件，替换之后需要分别做特别的设置，那就说明抽象得还不足够，会引入许多if-else，可以配置清单等方式消除接口隔离原则（ISP）目标：指导接口的定义【边界处理】内容不依赖任何不需要的组件、类、方法如果不同的用户分别使用一个大接口的几个不同方法，那么应该把这个大接口拆分为针对这些用户的小接口依赖反转原则（DIP）目标：指导依赖方向【依赖】内容：组件间跨越边界的源码依赖的方向永远与控制流的方向相反五、组件定

7、义：是软件的部署单元，是整个软件系统可以独立完成部署的最小实体拆分原则REP：复用、发布等同原则内容：软件复用的最小粒度应等同于其发布的最小粒度CCP：共同闭包原则内容：将为了相同目的而同时修改的类放在同一个组件中，是SRP原则在组件层面的描述执行对大部分应用程序而言，可维护性的重要性远远大于可复用性因为一个原因需要做修改，这个修改最好在同一个组件中，如果分散在多个组件中，那么开发、提交、部署的成本都会上升CRP：共同复用原则内容：不要强迫一个组件依赖它不需要的东西，是ISP原则在组件层面的描述张力图架构设计中有许多矛盾，研发性和复用性的矛盾，而研发性本身又有粘性（CCP）和排斥性（CRP）的

8、矛盾架构师做的往往是在这个张力图中找到一个最符合现在需要的点，而这个平衡也是不断变化的，根据项目的规模、迭代的节奏等依赖原则无依赖环原则互相依赖的组件，实际上组成了一个大组件，这三个组件要一起发布、一起做单元测试通过依赖反转原则可以解依赖环稳定依赖原则内容依赖必须指向更稳定的方向，接口是最稳定的组件的稳定性，指的是组件的变更困难度，影响因素有很多，比如代码的体量大小、复杂度、清晰度等，但是最重要的一个因素就是依赖的数量让组件难于修改的一个最直接的办法就是让很多其它组件依赖与它组件的稳定性和它的变更频繁度没有直接的关联。或者说，稳定性可以分为价值（需求）的稳定性，和组件自身的稳定性定量指标：不稳

9、定性(I)=出向依赖数量/(入向依赖数量 + 出现依赖数量)方法：可以通过抽接口，共同依赖接口的方式，修正违反稳定依赖的地方稳定抽象原则内容一个组件的抽象化程度应该与其稳定性保持一致为了防止高阶架构设计和高阶策略难以修改，通常抽象出稳定的接口或抽象类。越稳定的库就应该越抽象，这样它的稳定性就不会影响它的扩展性定量描述抽象程度(A)=组件中抽象类和接口的数量/组件中类的数量将不稳定性和抽象程度分别作为横轴和纵轴，画一个二维的图，(0,1)-(1,0)连线就是主序列线。靠近(0,0)的区域是痛苦区，改动成本很大，但是又很具体。靠近(1,1)的是无用区，非常抽象，但是没有别的组件依赖它，改动成本很小

10、，通常是废弃的。离主序列线的距离D=|A+I-1|，可以定量化的衡量一个组件的健康程度。在D满足期望的条件下，越靠近(0,1)和(1,0)越好六、封装方式经典的封装方式按层封装问题无法展现具体的业务领域不能防止跨层调用。通常情况下，绕过业务逻辑是不合理的，尤其是要控制权限时按功能封装端口和适配器按组件封装组织形式与封装的区别如果没有封装和隐藏功能，采用任何架构风格都没有区别七、软件架构目的终极目的：最大化程序员的生产力，最小化系统的总运营成本细化目标：支撑软件系统的全生命周期，让系统便于理解、易于修改、方便维护、轻松部署方针尽可能长时间地保留尽可能多的可选项选项指的是无关紧要的细节设计选项例子

11、具体选用哪个存储方式，或哪个数据库使用哪种web服务使用哪种框架边界越完善，开发和部署成本越高。所以不完全边界能解决的，不要用完全边界；低层次解耦能解决的，不要用高层次解耦内容组件拆分切分水平分层按用例垂直切分重复性解耦模式源码层次部署层次服务层次从上到下，开发、部署成本依次升高，如果低层次的解耦已经满足需要，不要进行高层次的解耦组件排列（依赖）依赖关系与数据流控制流脱钩，与组件所在层次挂钩。所以组件的依赖是与组件的水平分层息息相关的分层业务实体用例接口适配器框架与驱动程序测试层组件通信方式接口调用服务调用完全边界调用双方都声明接口专用的输入数据类型专用的返回数据类型不完全边界省掉最后一步：保留到源码层次的解耦；声明好接口，做好分割后，仍然放在一个组件中，等到时机成熟时再拆出来独立编译部署单向边界：正常的切割，应该使用两个接口，两个类各自使用对方的接口，而不是直接使用类，但是这样的开发成本很大，所以，只实现一个接口，高层用接口调用低层，而低层直接使用高层的类门户模式：控制权的间接转移不用接口和实现去做，而是用门户类去做，接口都不用声明了软件系统的生命周期开发不同团队负责的组件不交叉不使用大量复杂的脚手架部署减少组件数量，内部组件外部组件结