一.背景
最近被推荐了《演进式架构》一书，这里分享阅读心得和个人观点，与大家共同进步。
二.软件架构定义
1.软件架构：重要的东西
2.架构师职责：理解和权衡“重要的东西”
1).理解业务：领域需求
2).考虑技术特征：可审计性、性能、安全性、数据、合法性、伸缩性、软件柔性、质量、演进能力等
3.架构常见维度：技术、数据、安全、运维和系统
4.演进式架构：支持跨多维度的引导性增量变更。因为需求在变，架构要拥抱变化，持续演进，同时防止退化
5.演进式架构构成：增量变化、适应度函数、适当耦合
6.增量变更：变更发生时，要通过适应度函数对架构的关键维度进行保护。
(注：架构是不断努力的结果，是一个与开发工作紧密结合的过程)
三.适应度函数
定义架构关键维度，通过适应度函数来保证质量。
1.关键维度：性能、弹性
2.相关维度：代码质量
3.不相关维度：如生产周期，与架构无关维度
四.架构耦合
1.架构演进，首先检查当前架构是否模块化，在此基础上再做演进。
2.复用和服务隔离：服务隔离优于复用，如微服务架构，各服务尽量降低依赖，包括多个微服务会依赖公共的库。这个这做法和传统的单体架构的系统开发有差异。
3.架构分层：需要有分层思想，屏蔽不稳定的变化，如对数据库访问，需要隔离。
库和框架：库，如api，应用直接调用。 框架，调用应用代码。优先使用库的方式。框架的变更对整个系统变化冲击比较大。
五. 演进式架构的陷阱和发模式
1.供应商为王：整个系统不要围绕特定的组件，应该把这些组件看成整个系统的集成部件，可以替换。
2.复用：不要过度复用。
其他陷阱和反模式就不细介绍了。
六.总结
1.人为第一要素：方法和过程需要人去实施，具体结果的评判，不同的人可能有不同的结论。
2.架构需要生命：任何系统都需要演进，需要持续成长。不同阶段目标的定义和守护人的能力关系很大。
3.经验：持续学习，积累经验，对架构的认知会不断的变化；人和架构共同成长。
4.DeveOps:测试、持续集成和开发运维很重要，是产品输出质量的有效保障方法。
