演进能力是一种元特征和保护其他所有架构特征的架构封装器
IEEE 的软件架构定义中的4+1
视图模型。它关注不同角色的不同视角，将整个系统划分成了逻辑视图、开发视图、进程视图和物理视图
架构师确定了可审计性、数据、安全性、性能、合法性和伸缩性是该应用的关键架构特征。随着业务需求不断变化，每个架构特征都通过适应度函数来保护其完整性。
康威描述道，在设计的最初阶段，人们首先需要高瞻远瞩地思考如何将职责划分为不同的模式。团队分解问题的方式会左右他们之后的选择，这便是康威定律。
康威特别提醒软件架构师，不要只关注软件架构和设计，还应关注团队之间委派、分配和协调工作的方式。
演进式架构主要由三方面构成：增量变化、适应度函数和适当的耦合

适应度函数:

全系统适应度函数允许架构师通过统一的机制思考不同的问题，捕捉和保留重要的架构特征。
原子适应度函数与整体适应度函数、触发式适应度函数与持续式适应度函数、静态适应度函数与动态适应度函数、自动适应度函数与手动适应度函数\临时适应度函数、针对特定领域的适应度函数
尽早确定适应度函数、预设式高于应急式、审查适应度函数

实施增量变更:

只有成功完成了架构设计、实现、升级和无法避免的变更后，甚至当架构能够经受由前期未知的未知因素引起的反常事件（第6 章将介绍）带来的考验时，架构师才能评价架构的长期有效性
驱动敏捷软件方法论的引擎是内置的反馈环，如测试、持续集成和迭代等。然而包含应用程序最终用户的反馈环已经脱离了团队的控制。使用假设驱动开发，我们能以一种前所未有的方式将最终用户纳入构建流程，从他们的行为中学习并构建出对其真正有价值的系统

架构耦合:

模块化-模块意味着逻辑分组，而组件意味着物理划分。
架构的量子和粒度-架构量子则是具有高功能内聚并可以独立部署的组件，它包括了支持系统正常工作的所有结构性元素。在单体架构中，量子就是整个应用程序，每个部分都高度耦合，因此开发人员必须对其进行整体部署。微服务架构在架构元素之间定义了物理限界上下文，封装了所有可能变化的部分。这种架构就是为了增量变更而设计的。
不同类型架构的演进能力
-大泥团-非结构化单体、分层单体、模块化的单体架构、微内核架构、事件驱动架构
微服务架构通常遵循以下七个原则：
1-围绕业务领域建模，微服务的目标是创建有用的限界上下文，而不是让开发人员构建更小的服务
2-隐藏实现细节，微服务的技术架构封装在基于业务领域的服务边界中。每个领域形成一个物理限界上下文。服务间通过传递消息或资源来集成，而不是通过暴露实现细节集成
3-自动化文化，支持持续交付
4-高度去中心化，微服务形成了一种无共享架构，其目标是尽可能地减少耦合。通常重复好于耦合
5-独立部署，可以独立部署每个服务（包括基础设施），反映了服务间的物理限界上下文
6-隔离失败，每个服务都应该处理合理的错误场景并在可能的情况下将其恢复。
7-高度可观察
微服务的主要目标是通过物理限界上下文来隔离领域及理解问题领域。因此，它的架构量子就是服务，这使得它成为了演进式架构的优秀示例
常用于迁移的架构是基于服务的架构，有三个明显的区别，分别是服务粒度、数据库范围和集成中间件。
更大的服务粒度、数据库作用域、集成中间件
基于服务的架构内在的演进能力肯定比ESB 驱动的SOA 架构要好。开发人员偏离限界上下文的程度决定了架构量子的大小和破坏性耦合的数量。
“无服务”架构-BaaS（后端即服务）是那些明显或从根本上依赖于第三方应用或云端服务的应用、FaaS（功能即服务）

演进式数据:

是经过检验的、版本化的和增量的
架构师必须考虑应用的所有耦合特征，其中包括类、包/ 命名空间、库、框架、数据库模式，以及事务上下文。在架构演进时，忽视其中任一维度（或维度间的交互）都将产生问题。
在将单体架构迁移到某种更精细的架构时，应该从分离少量较大的服务开始。当构建一个全新的微服务架构时，开发人员应该尽量限制服务和数据上下文的大小。然后，不要仅按字面意思来理解微服务，对每个服务而言，小并不是必需的，能捕获有用的限界上下文才是关键。
数据的年龄和质量,识别真正有用的数据并将其保留下来，将旧数据作为参考但不将其纳入演进式开发的主流。

构建可演进的架构:

演进机制-通过下面三步来构建演进式架构
识别受演进影响的架构维度、为每个维度定义适应度函数、使用部署流水线自动化适应度函数
赋予现有架构演进能力取决于三个因素：组件耦合度、工程实践成熟度，以及开发人员构建适应度函数的难易程度。
团队可以通过多种划分方式将单体应用分解成服务。业务功能分组、事务边界、部署目标
演进模块间的交互-拆分共享的依赖、通过JAR文件共享依赖、复制共享的库以消除耦合点。共享就是耦合的一种形式，在微服务架构中这是非常不可取的
演进式架构构建指南-去除不必要的可变性、让决策可逆、演进优于预测、构建防腐层、服务模板、构建可牺牲架构、应对外部变化，传递依赖管理被视为有害的、更新库与更新框架、持续交付优于快照、服务内部版本化
演进式架构的陷阱和反模式-
为供应商为王反模式-无论从技术还是从业务流程的角度来看，将外部工具或框架置于架构的核心会严重限制架构的演进能力
陷阱：抽象泄漏底层抽象破坏会导致意外的灾难，即原始抽象泄漏，它是技术栈日渐复杂带来的副作用之一。
反模式：最后10%的陷阱在抽象范围的另一端存在着另一种复用陷阱，它隐藏在套装软件、平台和框架中。
反模式：代码复用和滥用-开发人员为实现可复用所添加的钩子越多，对代码的基本可用性损害越大。
微服务避免代码复用，遵循重复优于耦合的理念。
当耦合点妨碍了演进或其他重要的架构特征时，通过分叉或重复来打破耦合点。
架构师必须持续评估架构特征的适应度，保证它们仍在提供价值，避免沦为反模式。
陷阱：简历驱动开发不要为了架构而构建架构，构建架构是为了解决问题。在选择架构前，要始终理解问题域，不要本末倒置。
增量变更反模式：管理不当
当开发人员构建单体架构时，管理决策将影响所有项目。因此，在选择数据库时，架构师必须了解每个项目需要的能力，并考虑最复杂的情况。
陷阱：发布过慢，一个项目的生产周期决定了架构的演进速度。换句话说，演进速度和生产周期成正比
业务问题陷阱：产品定制为每个客户定制、永久的功能开关、产品驱动定制化
反模式：报表
陷阱：规划视野