演进式架构 原书第2版 pdf下载

适读人群 ：本书适合架构师、开发人员，以及本领域的学生阅读。
随着新工具、框架、技术和范式不断涌现，软件开发生态系统也在不断变化。仅在过去五年中，软件开发核心工程实践的不断进步就促使业界认识到架构本身必须如何发展才能满足不断变化的用户需求。本书通过现实世界的案例研究阐明了软件开发和架构设计日益增长的演进需求，提供了关于适应度函数、自动化架构治理等方面的新技术、知识和技巧，详尽阐述了演进式架构的工程实践和使之更容易的结构方法。

本书提供了关于适应度函数、自动化架构治理和演进式数据的技术、知识和技巧。本书分为三个部分：第一部分包括定义演进式架构机制的章节——介绍团队如何使用技术和工具来构建适应度函数、部署管道以及其他管理和演进软件项目的机制；第二部分包括围绕耦合、复用和其他相关结构考虑因素的架构风格和设计原则，以帮助读者实现清晰的长期演进；第三部分探讨了第一部分中介绍的工程实践与第二部分中的结构考虑因素的交叉点。

Neal Ford是Thoughtworks公司的总监、软件架构师和meme wrangler。
Rebecca Parsons博士是Thoughtworks的首席技术官。
Patrick Kua是一位拥有20多年经验的资深技术领导者。
Pramod Sadalage是Thoughtworks公司的数据兼DevOps总监，在数据库专业人员和应用开发人员之间架起了一座桥梁。

目录

原书第1版序
序
前言1

第一部分 机制
第1章 演进软件架构9
1.1 软件演进的挑战9
1.2 演进式架构12
1.2.1 引导式变更12
1.2.2 增量变更13
1.2.3 多种架构维度13
1.3 长期规划如何应对层出不穷的变化15
1.4 架构构建完成后，如何防止其随时间推移而退化17
1.5 为何演进17
1.6 小结18

第2章 适应度函数19
2.1 什么是适应度函数19
2.2 适应度函数分类23
2.2.1 按范围分类：原子与整体23
2.2.2 按节奏分类：触发式、持续式和时间式24
2.2.3 案例研究：触发式还是持续式25
2.2.4 按结果分类：静态与动态27
2.2.5 按调用方式分类：自动与手动27
2.2.6 按响应方式分类：预设式与应急式28
2.2.7 按覆盖范围分类：领域特定适应度函数28
2.3 谁来写适应度函数29
2.4 哪里有适应度函数测试框架29
2.5 结果与实现30
2.6 小结32

第3章 实现增量变更33
3.1 增量变更33
3.1.1 部署流水线36
3.1.2 案例研究：为PenultimateWidgets的发票服务增加适应度函数39
3.1.3 案例研究：使用自动化构建验证API的一致性41
3.2 小结44

第4章 自动化架构治理46
4.1 架构治理之适应度函数46
4.2 基于代码的适应度函数47
4.2.1 传入/传出耦合48
4.2.2 抽象性、不稳定性和与主序列的距离50
4.2.3 导入的方向性53
4.2.4 圈复杂度和“引导式”治理54
4.3 即插即用的工具56
4.3.1 开源库的合法性56
4.3.2 可访问性和支持的其他架构属性57
4.3.3 ArchUnit57
4.3.4 代码治理的lint工具62
4.3.5 案例研究：可用性适应度函数62
4.3.6 案例研究：配合金丝雀发布的负载测试62
4.3.7 案例研究：移植什么63
4.3.8 已经在使用的适应度函数64
4.4 集成架构65
4.4.1 微服务架构中的通信治理65
4.4.2 案例研究：如何实现适应度函数67
4.5 DevOps69
4.6 企业架构72
4.6.1 案例研究：每天部署60次的架构重构74
4.6.2 保真度适应度函数76
4.7 适应度函数作为清单，而非棍棒76
4.8 记录适应度函数77
4.9 小结79

第二部分 结构
第5章 演进式架构拓扑83
5.1 可演进的架构结构83
5.1.1 共生性83
5.1.2 共生性与限界上下文的交集87
5.2 架构量子和粒度88
5.2.1 独立部署89
5.2.2 高功能内聚性90
5.2.3 高静态耦合90
5.2.4 动态量子耦合95
5.3 契约97
案例研究：微服务作为演进式架构101
5.4 复用模式105
5.4.1 有效的复用=抽象+低变动性106
5.4.2 Sidecar和服务网格：正交操作的耦合107
5.4.3 数据网格：正交数据耦合110
5.5 小结114

第6章 演进式数据115
6.1 演进式数据库设计115
6.1.1 演进模式115
6.1.2 共享数据库集成117
6.2 不适当的数据纠缠121
6.2.1 两段式提交事务122
6.2.2 数据的历史和质量123
6.2.3 案例研究：演进PenultimateWidgets的路由124
6.3 从原生到适应度函数125
6.3.1 引用完整性126
6.3.2 数据冗余127
6.3.3 替换触发器和存储过程129
6.3.4 案例研究：从关系型到非关系型的演进130
6.4 小结131

第三部分 影响
第7章 构建可演进的架构135
7.1 演进式架构的原则135
7.1.1 最后责任时刻135
7.1.2 针对可演进性进行架构设计和开发136
7.1.3 波斯特尔定律136
7.1.4 针对可测试性进行架构设计137
7.1.5 康威定律137
7.2 机制137
7.2.1 步骤1：识别受演进影响的维度137
7.2.2 步骤2：为每个维度定义适应度函数137
7.2.3 步骤3：使用部署流水线自动化适应度函数138
7.3 绿地项目138
7.4 改造现有架构138
7.4.1 适当的耦合和内聚138
7.4.2 商业软件的影响140
7.5 迁移架构141
7.5.1 迁移步骤142
7.5.2 演进模块之间的交互144
7.6 构建演进式架构的指南147
7.6.1 消除不必要的变化148
7.6.2 做出可逆的决策149
7.6.3 倾向可演进而非可预测150
7.6.4 构建防腐层150
7.6.5 构建可牺牲的架构152
7.6.6 缓解外部变化153
7.6.7 更新库而不是框架155
7.6.8 版本服务内部化156
7.6.9 案例研究：演进PenultimateWidgets的评分156
7.7 适应度函数驱动的架构158
7.8 小结159

第8章 演进式架构的陷阱和反模式160
8.1 技术架构160
8.1.1 反模式：最后10%陷阱和低代码/无代码160
8.1.2 案例研究：PenultimateWidgets里的复用161
8.1.3 反模式：供应商为王162
8.1.4 陷阱：充满漏洞的抽象163
8.1.5 陷阱：简历驱动开发165
8.2 增量变更166
8.2.1 反模式：不恰当的治理166
8.2.2 案例研究：PenultimateWidgets中恰到好处的治理168
8.2.3 陷阱：发布速度过慢168
8.3 业务因素169
8.3.1 陷阱：产品定制170
8.3.2 反模式：记录系统之上的报表系统170
8.3.3 陷阱：过于长远的规划171
8.4 小结172

第9章 实践演进式架构173

9.1 组织因素173

9.1.1 不要抗拒康威定律173

9.1.2 文化182

9.1.3 试验文化183

9.1.4 首席财务官和预算184

9.2 业务场景185

9.2.1 假设驱动开发和数据驱动开发186

9.2.2 适应度函数作为试验媒介187

9.3 构建企业级适应度函数191

9.3.1 案例研究：零日安全漏洞192

9.3.2 在现有集成架构中拆分限界上下文193

9.4 从哪里开始195

9.4.1 触手可及的成果195

9.4.2 最高价值优先196

9.4.3 测试196

9.4.4 基础设施196

9.4.5 案例研究：PenultimateWidgets的企业级架构197

9.5 未来状态198

9.5.1 使用AI的适应度函数198

9.5.2 生成式测试198

9.6 构建演进式架构的场合199

9.6.1 什么情况下公司应该构建演进式架构199

9.6.2 什么情况下公司不需要构建演进式架构201

9.7 小结202

前言

当我们在2017年写作本书第1版时，演进式架构的想法仍然有些激进。在Rebecca关于这个主题进行第一次演讲后，有人指责她缺乏职业责任感，因为她提出软件架构可以随着时间的推移而演进—毕竟，架构是永远不会改变的东西。
然而，正如现实告诉我们的那样，系统必须演进以满足其用户的新需求，并反映不断变化的软件开发生态系统。
第1版出版时，很少有工具可以利用我们描述的技术。幸运的是，软件开发世界在不断发展，逐渐有了更多的工具使构建演进式架构变得更容易。
本书结构
我们改变了第1版的结构，更清晰地划分了两个主要主题：演进软件系统的工程实践和使之更容易的结构方法。
在第一部分，我们将定义各种机制和工程实践，团队可以使用它们来实现演进式架构的 目标，包括读者需要了解的技术、工具、类别和其他信息。
软件架构还涉及结构设计，某些设计决策可以使演进（和治理）更容易。我们将在第二 部分中介绍这一点，该部分还包括架构风格的覆盖范围，以及有关耦合、复用和其他相 关结构考虑因素的设计原则。
软件架构中几乎没有任何东西是孤立存在的，演进式架构中的许多原则和实践在软件开发过程中许多部分盘根错节，我们将在第三部分中进行介绍。
案例研究和 PenultimateWidgets本书中我们突出了一些案例研究。四位作者在撰写本书时都是（有些人现在仍然是）顾问，我们利用我们的实际经验推导出本书中出现的许多案例研究。虽然不能透露特定客 户的详细信息，但我们希望提供一些相关示例，使主题不那么抽象。因此，我们采取了 替身公司“PenultimateWidgets”的想法，让它作为所有案例研究的“主角”。
在写作第2版时，我们还向同事们征集了案例研究，这更凸显了应用所探讨的技巧的用例。在本书中，虽然每个案例研究都以 PenultimateWidgets 的用例呈现，但它们其实都 源自真实项目。