贯通演进式架构的三个方面：适应度函数、增量变更、适当的耦合

演进式架构有三个主要方面: 适应度函数、增量变更、适当的耦合。测试存在了很多年，但并不是以适应度函数的形式强调架构验证的。持续交付定义了部署流水线，演进式架构展示了这一能力的实际效用。运用这些能力构建更复杂的架构，随着现实世界不断演进。

第一步，识别受演进影响的架构维度。架构师必须确定在演进中他们想要保护的架构维度。包含技术架构，数据设计，安全，可伸缩性，其他重要特征。逆康威时刻对此很有帮助，它鼓励组织多角色团队。

第二步，为每个维度定义适应度函数。为了保证代码的架构特征，架构师通常将一系列代码衡量指标构建到部署流水线中，例如避免组件循环依赖。适应度函数可以自动或手动触发。

第三步，使用部署流水线自动化适应度函数。架构师必须在项目中推进增量变更，在部署流水线中定义不同阶段来执行适应度函数并关联部署实践，例如环境准备
测试和其他DevOps问题。增量变更是演进式架构的引擎，它让我们可以通过部署流水线主动验证适应度函数，并通过高度自动化隐藏一些单调的任务，例如无感知部署。一旦项目的生产周期延长，将使项目交付新版本的速度减慢，进而影响演进能力。

为新项目构建演进能力比改造已有项目容易。开发人员可以立即进行增量变更，在项目初期构建部署流水线。在编写代码前，确定和设计适应度函数将更容易，也便于将适应度函数纳入系统，因为在项目初期项目脚手架已经搭建完成了。架构师无需理清那些蔓延到现有系统的耦合点。架构师可以让度量和其他验证机制就位从而保证项目变更时架构的完整性。

赋予现有架构演进能力取决于三个因素: 组件耦合度、工程实践成熟度、开发人员构建适应度函数的难易程度。组件间的耦合程度决定了技术架构的演进能力。如果数据库模式死板，即使最有演进性的架构也会失败。清晰解耦的系统易于演进。工程实践对定义架构的可演进性至关重要。构建演进式架构的最大障碍是棘手的运维工作。如果开发人员无法轻松地部署变更，反馈环的各个部分都会受阻。适应度函数是演进式架构的保护层。希望架构师将各种架构验证机制视为适应度函数，例如伸缩性相关的服务级别协议，还有围绕安全需求的业务规则及附带的验证机制。

将所有架构视为适应度函数。商业成品软件COTS也要随着其他应用一起演进、努力使集成点保持一定的成熟度。

赋予现有架构演进能力极具挑战。首先去除不必要的可变性。通过不可变基础设施取代雪花服务器，现代DevOps在其领域内解决了动态平衡的问题。不可变基础设施是完全以程序的方式定义的系统，所有对系统的变更必须通过代码完成，而不是修改运行中的操作系统。从运维的角度看，整个系统是不可变的，一旦开始运行，就不会发生变化。构建可演进的软件系统意味着尽可能控制未知因素。第二，让决策可逆。DevOps实践使那些需要被撤销的决策变得可逆，例如蓝绿部署。功能开关是开发人员使决策可逆的另一种常见形式。第三，演进优于预测。虽然未知问题无法预测，但我们知道动态平衡导致了软件开发领域的不可预测性。我们将演进能力构建在软件中。第四，构建防腐层。使用防腐层有助于系统的演进性。