前言
大家好，我是春风，最近需要进入一段空窗期，空闲之余，我便从公司图书角翻出一本Bob大神的《架构整洁之道》，尽管才看到一半，但其中的播种曾经不得不让我想停下来先总结记录一下了，这应该是架构设计畛域最好的一本启蒙书了吧！
第一局部：概述
第一局部就是答复一个问题：咱们架构设计的终极目标是什么？
作者首先给出了掂量一个软件系统价值的两个维度：
- 行为价值（让机器依照咱们给出的指令运行，从而给使用者提供价值）
- 架构价值（软件必须放弃灵便，面对简单的情景，能够最低老本的实现变更）
而这两种价值到底哪种更重要呢？作者援用艾森豪威尔矩阵：
行为价值-咱们当下的第一要务是满足客户需要，所以它是紧急而不重要；
架构价值-当下站在业务方的角度来说，不紧急，然而为了能应答后续的变更，无疑是十分重要。
所以，咱们架构的指标应该是发明架构价值，即用最小的人力老本来满足构建和保护零碎的需要（尤其是最小人力老本保护，这里的保护我了解就是适应变更）
第二局部：编程范式-代码层面
本书的第二局部到第五局部其实是自下而上的阐明该怎么设计一个好的架构。第二局部是代码层面；
第三局部是组件外部如何构建；第四局部是组件内部之间如何关联；第五局部是软件系统层面。
第二局部从代码层面给出了三大编程范式，其实就是限度咱们不能做哪些内容。
1. 结构化编程
咱们的软件系统须要依据性能来做降解拆分，大型零碎能够拆分成模块和组件，在这些模块和组件中，又能够进一步拆分成更小的函数，
结构化编程在代码层面就更像是咱们函数的编写标准，任何一个简单的函数构造都是程序构造和分支构造、循环构造的汇合，同时这三种根底构造是可被证实的，所以任何简单的函数也就是可推导的。
这里有个非凡的反例就是goto，goto能跳脱这三种结，所以为了咱们整个函数是可推导的，个别都会放弃应用goto这种构造。
结构化编程的价值就是通过功能性降解拆分，使得咱们领有了发明可推导程序单元的能力，进而编写可推导程序的能力。
2. 面向对象编程
面向对象是将程序的控制权间接转移给了对象
面向对象有三大个性：封装、继承、多态，这也是咱们Java最陈词滥调的面试题了
- 封装：采纳封装个性，咱们能够把一组相关联的数据和函数圈起来，使圈里面的代码只能看见局部函数（为什么是局部封装？c语言其实就是齐全封装，因而也恰好减弱了面向对象的完美性），数据则齐全不可见，函数封装能够让调用者不必关怀函数的实现过程。
- 继承：让咱们能够在某个作用域内对外部定义的某一组变量和函数进行笼罩。继承是相比于非面向对象语言，提供了向上转型的便捷。
多态：父类的办法被子类重写时，能够各自产生本人的性能行为。多态其实是函数指针的一种利用，然而打消了函数指针的危险性。多态的益处是当程序要减少一种领域内的实现时，只须要重写办法减少其本人的实现即可。
在咱们应用多态前，函数的调用方都必须援用被调用方所在的模块，应用多态后，调用方能够通过形象接口调用，而不再间接依赖被调用方，这种控制权的反转就是依赖反转。
这也是面向对象最大的益处，依赖反转不仅在函数调用中作用突出，前面要讲的组件依赖上也是功能强大，正是组件之间不必间接依赖给组件提供了可独立部署的能力，
面向对象就是以多态的伎俩来对源代码中的依赖关系进行管制，这种控制能力能够让咱们构建出各种插件或架构，让高层策略性组价与底层实现组件相拆散，底层组件也因而具备了独立部署和独立开发的能力。
3. 函数式编程
区别于按功能性拆解的结构化，咱们须要从可变性的角度来做程序的隔离。行将程序划分为可变组件和不可变组件。
为什么要做可变性的隔离？
因为咱们程序的所有竞争，像Java的死锁、并发更新的平安问题都是批改可变变量导致的，可变性隔离能够拆散出这些竞争状态，从而进一步防止并发的平安问题。
这里把不可变组件了解为咱们的业务代码层（service层），可变组件了解为咱们的数据库层，所以咱们始终都是在恪守这种编程范式，将大部分业务逻辑归于不可变组件中，而为了能防止可变变量的竞争状态的产生，咱们通常采纳事务型内存（数据库的实现）或者重试机制。
可变变不可变
除了这两种形式，书中也有一个乏味的爱护可变变量的形式，就是将可变性变成不可变。比方咱们在银行存取款，每次存取款都须要将余额加一减一，这个余额就是一个可变变量，然而如果内存足够大，咱们就能够不去每次批改余额，而只保留存取款记录，当要查问余额的时候，再将所有的存取款记录做一遍计算。
这样余额这个可变变量也就成了不可变，不存在更新，也就不存在并发问题。但这无疑对内存和性能是一项很大的挑战。这个的衡量关系让我想到了驰名的CAP实践。
第三局部：设计准则-如何构建一个组件，即咱们模块级编程的五大准则：SOLID
首先阐明咱们模块级编程（中层构造）的三个次要指标是：
- 使软件可容忍被改变；
- 使软件更容易被了解；
- 构建可在多个软件系统中复用的组件
为了实现这些指标，构建一个组件的时候，便须要咱们遵循SOLID准则：SOLID也是这五大准则的首字母缩写
SRP:繁多职责准则
任何一个软件模块都应该只对某一类行为负责。这里的软件模块能够了解为就是一组严密相干的函数和数据，即咱们Java中的类。所以SRP也更像是规定类的划分。定义中对其负责的某一类行为也就是咱们这个模块有且只有的一个被扭转的理由。
违反SRP的反例：
OCP：开闭准则
对扩大凋谢，对批改敞开
开闭准则通常采纳架构分层（MVC） + 依赖反转的形式来实现。使得高阶组件不会因为低阶组件的批改而受到影响，从而使得只用扩大低阶组件就能够满足更多的业务性能。
LSP：里氏替换准则
通过继承（父类与子类的替换）或者接口与实现类的替换来实现，这也是不便扩大一个形式。如果违反了LSP，零碎将不得不为此减少大量的应答变动的机制。
ISP：接口隔离准则
后面繁多职责准则和开闭准则都是讲如何将一组程序划分到一起，然而任何档次的软件设计如果依赖了它并不需要的货色，就会带来不必要的麻烦。
所以ISP就是拆散出那些不须要的依赖，通常采纳的形式是将原来须要间接依赖的某个类改为依赖某个拆散的接口。
DIP：依赖反转
在源代码档次的依赖关系中，咱们应该多用形象类型，而非具体实现。
咱们每次批改接口的时候，肯定会去批改具体实现，然而批改具体实现的时候，却很少须要批改接口，所以咱们也能够认为接口比实现更稳固，而依赖关系中，咱们便也应该依赖这种更稳固的构造来缩小应答变更带来的批改难度。
为谋求这种架构上的稳定性，在编码层面能够归结为上面这几条具体的编码守则：
- 应在代码中多应用形象接口，尽量避免应用那些多变的具体实现。
包含对象的创立过程，因为所有面向对象的语言中，创建对象都免不了要在源代码档次上依赖该对象的具体实现，所以为了防止依赖具体实现，咱们会采纳形象工厂模式来创立，这也是spring创立bean的模式。 - 不要在具体实现类上创立衍生类，就是咱们常说的少用继承，多用组合。
继承关系是所有源代码依赖关系中最强的、最难被批改的。 - 不要希图通过笼罩蕴含具体实现的函数，来扩大性能.
因为即便笼罩，咱们也无奈打消对具体实现的依赖，惟一的办法就是创立一个新的抽象类。 - 应防止在代码中写入与任何具体实现相干的名字，或者其余容易变动的事物的名字。
DIP不能齐全打消对具体实现的依赖，当防止不了违反DIP的时候，咱们能够将这部分进行隔离。
图中逾越边界、朝向形象层的依赖关系则会成为一个设计守则：依赖守则。
形象工厂模式：
第四局部：组件准则-组件之间如何划分、关联
SOLID是领导咱们如何将砖块气成墙与房间，那组件准则就是领导咱们如何将这些房间组合成房子。
程序的墨菲定律+摩尔定律使得咱们有开发插件化架构的必要和可能。
首先再定义一下组件这个概念：能够独立部署的最小实体。也是一份可重定位的二进制文件。像Java中一个jar包。
这里了解可重定位就是能够晓得并批改咱们加载依赖的地位。
构建组件的根本准则：
- REP:复用/公布等同准则
- CCP：独特闭包准则
- CRP：独特复用准则
复用/等同准则：
软件复用的最小粒度应等同于其公布的最小粒度。
咱们最罕用的模块管理工具：maven，治理了咱们要依赖的所有组件，而这些引入的每一个独立组件都是能够独自公布的，也是能够在任何零碎独自援用的。
其中每一个依赖的组件都有一个独特的主题，而且都有本人的版本治理，正因为有版本治理，咱们才能够在依赖时，有针对的抉择，防止依赖的版本更新对原先调用方造成影响。
独特闭包准则：
应该将那些会同时批改，并且为雷同目标而批改的类放在同一组件中.
这也是繁多职责准则在组件层面上的再度论述。变更体现在同一个组件，其它组件就不必再重新部署，所以咱们要将某一类变更所波及的所有类尽量聚合到一起。
独特复用准则：
不要强制一个组件的用户依赖他们不须要的货色，所以一个组件中，不是严密相连的类不应该放在一起，这也是接口隔离准则在组件层面的体现。
这里总结一下，三准则并不是都要齐全的遵循，也不可能都齐全遵循，而是在软件开发的过程中，侧重点一直的调整。比方在晚期，组件的划分更加偏向于业务性能，而料想不到太多的复用场景，所以CCP比REP更重要。
后面三准则标准了组件的划分，那组件之间的互相关联耦合同样也须要遵循上面这四个准则：
无依赖环准则：
即不应该呈现循环依赖。
后面介绍过，为了依赖者不受到被依赖者批改的被动影响，咱们通常的做法是版本治理，让依赖者自行决定依赖内容，但这个前提是不能呈现循环依赖。
而当呈现了循环依赖的状况，咱们就要应用
- 依赖反转，让依赖者依赖形象接口
创立新的组件，切离开循环依赖的局部
这两种形式来突破循环依赖。
自下而上的设计准则：
你会发现咱们本书解说的架构程序也就是这样自下而上的。
从源代码层面始终到组件到零碎，所以组件结构图必须随着软件系统的变动而变动和扩张，而不可能在零碎构建的最后就被完满设计进去。
稳固依赖准则：
依赖关系必须趋向于更稳固的方向。因为稳定性与变更难度无关。每个组件都有一个可计算的稳固指标，即 出向依赖占所有依赖的占比，稳固依赖准则通知咱们出向依赖应该尽可能的少，但也并不是所有组件都应该是稳固的，个别的高层架构反而是不稳固的，越底层越应该稳固。即底层应该是最多被依赖的，而最小依赖别人的。
稳固形象准则：
一个组件的抽象化水平应该与其稳定性保持一致。
具体说就是稳固的组件同时也应该是形象的。这样它的稳定性就不会影响到它的扩大；而相同，不稳固的组件反而应该蕴含具体的实现代码，这样它的不稳定性就能够通过具体的代码被轻易的批改。
组件的稳定性与抽象化水平应该是在下图中一个主序列左近。
以上就是我浏览《架构整洁之道》1-14章内容的对架构设计常识方面的播种，另外也有一些其余的感悟，与君共勉：
读书有时会比通过百度学习能了解的更深，很多优良的博客会帮咱们总结出每一个知识点，但往往没有书中作者那样会给你形容出整个常识的背景以及前因后果。
就像我这篇读书笔记一样，也都是我本人消化后再整顿出的内容，其中不乏我本人的主观形容，我本人能了解，但同样的话在你心里就不肯定能表白出同一个意思。
而且咱们平时接触的知识点太过系统，就像咱们学习maven，学习它的每一个命令，但却素来没想过，为什么要用maven这种形式来治理依赖，为什么要设计出版本？
- 及时输入能力加深本人对常识的了解，或者说一个常识只有你能用本人的话输入进去，能力证实这个常识你是真正的把握了。
- 写博客什么时候都不晚。肯定要写起来。
所以这也是为什么我做了这么多年程序员，却是公布第一篇文章的起因。但从当初开始，我会保持输入。咱们独特成长
我是春风，春风温煦，不负归期。公众号：程序员春风
最初的最初，码字不易，能看到这里，求个赞！