最近看完了一本大佬很早就推荐的书：《演进式架构》
现在看已经算是一本很老的书了，里面的很多概念对架构师来讲已经算是耳熟能详了。
如果你没有一些常识性思考，那还是可以看看的，如果没有时间，我通过这篇读书笔记梳理了书中的核心知识点，结合最近的一些新书观点，方便你快速获取这些知识。
演进式架构
架构的定义
每一本讲架构的书籍，基本都要先阐述一下，然而很书籍都给出了相同的答案，那就是Ralph Johnson的定义：
“架构是那些重要的东西…………无论它具体是什么”
这本书也没有例外。想了解最新架构及架构师解读，可以阅读最新的一本书籍《软件架构》读书笔记
何为演进式架构
架构的第一定律是：架构中的一切都是权衡
架构师在很多方面和骑独轮车的人一样，不断地平稳以适应环境变化。
然而架构师无论怎么努力，软件依然出现两个突出的问题：
架构构建完成后，会出现退化叫架构比特衰减，我们也称为架构腐化。
软件组成部分随着时间推移变得愈发脆弱和难以变更。
如何应对，演进式架构应运而生：演进式架构支持跨多个维度的引导性增量变量，主要由三方面构成：增量变更、适应度函数、适当的耦合。
增量变更
增量变量描述了软件架构的两个方面：如何增量地构建软件和如何部署软件
引导性变更
一旦架构师选择了重要的架构特征，他们会把变更引导进入思想史，以保护这些重要特征。
何为架构特征：在《软件架构》有详细描述，可看上面提到的读书笔记。
怎么保护这些架构特征，引入“适应度函数”，该函数是一种目标函数，用于计算潜在的解决方案与既定目标的差距。在演化计算中，适应度函数决定一个算法是否在持续提升。
适应度函数的隐喻涵盖多种机制，包括度量、测试和其他检验工具。为某些架构特征提供了客观的完整性评估。也体现了系统架构特征的保护机制。
多个维度
软件架构师往往关注技术架构，但那只是软件项目的维度之一。
除了技术，还有可审计性、数据、安全性、性能以及伸缩性等关键特征。我们强调架构整体的重要性，技术架构耦合以及数据耦合都影响架构演进，耦合不仅仅是项目的结构元素，甚至团队结构对架构都有着影响，所以才有了康威定律与逆康威定律。
适当的耦合
很多架构师认为耦合是必然之恶，但如果不依赖其他组件（并与其耦合）又很难构建复杂的软件。因此不能有耦合创伤应激障碍，对耦合有条件反射式恐惧。要客观看待耦合，并且要以最小的开销和成本最大程度地获益。
谈到耦合，必谈模块化。平台不同，代码复用机制也不同，但它们都支持将相关代码组成模块。模块化描述了相关代码的逻辑分组。可以以不同的物理方式封装模块。组件就是模块的物理封装。模块意味着逻辑分组，而组件意味着物理划分。
拆分组件有助于一些工程实践，例如构建和部署。库是一类组件，它往往和调用代码在相同的内存地址内运行，通过编程语言的函数调用机制进行通信。别一类组件被称为“服务”，如微服务，运行期依赖。
所有模块化机制都有助于代码复用，在任何级别尝试复用代码都是明智的选择，无论单一的函数，还是封装好的业务平台。
量子是物理实体相互作用时所涉及的最小单位。架构量子则是具有高功能内聚并可以独立部署的组件，它包括了支持系统正常工作的所有结构性元素。
如现在火热的DDD中，其中限界上下文的概念，所有领域相关内容在该领域同可见，但不对其他限界上下文可见。
构建演进式架构的关键之一在于决定自然组件的粒度以及它们之间的耦合，以此来适应那些通过软件架构支持的能力。
架构师一直在与耦合斗争，架构一直在演进，最原始的大泥球架构进化到单体分层架构再到微服务架构。
在重建昂贵的架构之前，提升现有架构的模块程度能让架构师获益。如果已经没有可以提升的地方了，那么这便是开始重建更加复杂的架构好时机。
实践演进式架构
从何开始实践？不仅实践演进式架构，其实实践其他任何架构都有一些通用策略：
1、容易实现的目标：将风险降至了最低，但可能牺牲价值。
2、最高价值优先：原因一：选择价值最高的部分表明决心。原因二：能明确演进式架构的长远价值。原因三：用最有价值的部分来审查此架构方法，能够为是否继续提供可行的数据。
构建可演进的架构会耗费额外的时间和精力，但好处是公司可以应对市场的重大变化，而不需要大量返工。
总结
简而言之，《演进式架构》提供了一种架构迭代的指导方法，就如同重构代码一样。
首先要有目标，以终为始，知道架构最终形态。也就是引导性变更。
其次需要模块化，提升扩展性，这是演进式架构的基础，寻找最合适的组件粒度，对于大泥球架构，整体应用就是架构量子，没法迭代式增量变更。
最后要有适应度函数，才能保障演进的正确与成功。就如同重构，得有UT的保障，不然谁敢重构，并且知道演进的效果。
