基本信息
- 作者： [美]穆拉特·埃尔德(Murat Erder),[美]皮埃尔·普约尔(Pierre Pureur),[美]伊恩·伍兹(Eoin Woods)
- 丛书名： 架构师书库
- 出版社：机械工业出版社
- ISBN：9787111717744
- 上架时间：2023-1-31
- 出版日期：2023 年1月
- 开本：16开
- 版次：1-1
- 所属分类：计算机 > 软件工程及软件方法学 > 软件方法/软件工程
【插图】
编辑推荐
Gartner权威发布2023年十大科技趋势之一“可持续IT架构”，可持续架构得到越来越多从业人员认同。
本书用自顶向下的方法阐述“持续架构”：在持续架构六准则下，结合敏捷和DevOps和云时代等环境因素综合考虑可伸缩性、性能、安全、数据等维度的架构决策，辅以策略和案例。
内容简介
作译者
穆拉特·埃尔德（Murat Erder）
“持续架构”之父，德意志银行董事、行政办公室CTO、数据办公室主管，在软件研发和架构领域有超过25年的经验，是一位资深的软件架构专家和管理顾问。于2015年在与穆拉特·埃尔德（Murat Erder）合著的《持续架构：敏捷中的持续架构》一书中提出“持续架构”的概念，自此之后，一直在世界范围内以实践、写作、演讲、咨询等方式进行持续架构的深化和布道工作。
皮埃尔·普约尔（Pierre Pureur）
“持续架构”之父，有近35年的软件开发和架构经验，IEEE会员。擅长企业架构、应用架构、信息架构、解决方案架构等几乎所有与架构相关的领域，曾担任某大型金融服务公司的首席企业架构师，在金融领域有丰富的技术和服务经验。于2015年在与穆拉特·埃尔德（Murat Erder）合著的《持续架构：敏捷中的持续架构》一书中提出“持续架构”的概念，并与其共同在世界范围内开展持续架构的布道工作。
伊恩·伍兹（Eoin Woods）
纽交所上市跨国软件公司Endava的CTO，有超过30年的软件开发和架构经验。英国工程技术学会（IET）特许会员，英国计算机协会（BSC）特许会员。于2018年获得获得由卡内基·梅隆大学的美国软件工程研究所（CMU SEI，全球软件工程领域最权威机构）颁发的Linda M. Northrup软件架构大奖。著有《软件系统架构》《软件架构指标》等架构领域的畅销著作。
“持续架构”之父，德意志银行董事、行政办公室CTO、数据办公室主管，在软件研发和架构领域有超过25年的经验，是一位资深的软件架构专家和管理顾问。于2015年在与穆拉特·埃尔德（Murat Erder）合著的《持续架构：敏捷中的持续架构》一书中提出“持续架构”的概念，自此之后，一直在世界范围内以实践、写作、演讲、咨询等方式进行持续架构的深化和布道工作。
皮埃尔·普约尔（Pierre Pureur）
“持续架构”之父，有近35年的软件开发和架构经验，IEEE会员。擅长企业架构、应用架构、信息架构、解决方案架构等几乎所有与架构相关的领域，曾担任某大型金融服务公司的首席企业架构师，在金融领域有丰富的技术和服务经验。于2015年在与穆拉特·埃尔德（Murat Erder）合著的《持续架构：敏捷中的持续架构》一书中提出“持续架构”的概念，并与其共同在世界范围内开展持续架构的布道工作。
伊恩·伍兹（Eoin Woods）
纽交所上市跨国软件公司Endava的CTO，有超过30年的软件开发和架构经验。英国工程技术学会（IET）特许会员，英国计算机协会（BSC）特许会员。于2018年获得获得由卡内基·梅隆大学的美国软件工程研究所（CMU SEI，全球软件工程领域最权威机构）颁发的Linda M. Northrup软件架构大奖。著有《软件系统架构》《软件架构指标》等架构领域的畅销著作。
目录
赞誉
推荐序
译者序
前言
致谢
第1章 软件架构的重要性更胜往昔 1
1.1 我们所说的架构到底是什么 1
1.2 当今的软件行业 2
1.3 当前软件架构的挑战 4
1.3.1 关注技术细节而不是业务
场景 4
1.3.2 认为“架构不能增加价值” 4
1.3.3 架构实践也许太慢了 5
1.3.4 一些架构师可能并不适应
云平台 6
1.4 敏捷化世界里的软件架构 6
1.4.1 一切的开始：软件架构与
极限编程 6
1.4.2 我们究竟在哪一步：架构、
敏捷性还是持续交付 7
推荐序
译者序
前言
致谢
第1章 软件架构的重要性更胜往昔 1
1.1 我们所说的架构到底是什么 1
1.2 当今的软件行业 2
1.3 当前软件架构的挑战 4
1.3.1 关注技术细节而不是业务
场景 4
1.3.2 认为“架构不能增加价值” 4
1.3.3 架构实践也许太慢了 5
1.3.4 一些架构师可能并不适应
云平台 6
1.4 敏捷化世界里的软件架构 6
1.4.1 一切的开始：软件架构与
极限编程 6
1.4.2 我们究竟在哪一步：架构、
敏捷性还是持续交付 7
前言
距离我们（Murat和Pierre）出版《持续架构》一书已经好几年了，这期间发生了很多变化，尤其是技术领域。因此，我们与Eoin Woods一起着手更新这本书。刚开始只是简单的修订，但慢慢地就演变成了这本新书。
《持续架构》主要是对概念、思想和工具进行概述和讨论，而本书则提供了更多基于实践的建议，侧重于指导读者如何利用持续架构方法，并涵盖了有关安全性、性能（performance）、可伸缩性、弹性、数据和新兴技术等主题的深入且最新的信息。
我们重新审视了架构在敏捷、DevSecOps、云和以云为中心的平台中的作用，也为技术人员提供了一份实用指南，指导他们通过不断更新经典软件架构实践的方式来应对当今应用程序所面临的一些复杂挑战。我们还重新审视了软件架构的一些核心主题：架构师在开发团队中的角色；如何满足软件涉众的质量属性需求；架构在实现如安全性、可伸缩性、性能和弹性等关键交叉需求方面的重要性。对上述每个领域，我们都提供了使架构实践有意义的一种新方法，这种方法通常建立在上一代软件架构相关书籍给出的传统建议之上，并解释了如何在现代软件开发环境中应对这些领域的挑战。
本书的结构如下：
第1章提供场景，定义术语，并概述在每章都会使用的案例研究（附录A包含了有关案例研究的详细信息）。
第2章列出我们的主要思想，希望读者了解如何在当今的软件开发环境中开展架构工作。
第3～7章探讨对现代应用程序开发来说至关重要的相关架构主题：数据、安全性、可伸缩性、性能和弹性。我们解释软件架构方法，尤其是持续架构方法，探讨如何在解决各个架构问题的同时保持敏捷的工作方式，以持续地向生产环境交付变更。
第8章和第9章主要着眼于未来，讨论架构在处理新兴技术方面的作用，并总结当今敏捷和DevOps时代下架构实践遇到的挑战以及应对这些挑战的一些潜在方法。
我们希望想成为软件架构师的读者了解该领域的经典基础知识（可能来自Software Architecture in Practice或Software Systems Architecture之类的书籍），同时认识到需要更新方法以应对当今快速发展的软件开发环境所带来的挑战。想要了解架构和设计的软件工程师也可能会被书中实用的、面向交付的重点内容所吸引。
为了使本书只涉及必要的内容并专注于上一本书以来发生的变化，我们假设读者已经熟悉包括信息安全、云计算、基于微服务的架构以及常见的自动化技术（例如自动化测试和部署流水线）在内的主流技术基础知识。我们希望读者熟悉架构设计的基本方法，了解如何创建软件的可视化模型以及领域驱动设计（Domain-Driven Design，DDD）等相关方法。如果读者对架构设计基础没有把握，我们建议从定义明确的方法开始，例如软件工程研究所的属性驱动设计或其他更简单的方法（如Software Systems Architecture第7章中概述的方法）。虽然软件建模被忽视了几年，但似乎正在重新回归主流实践。对于一开始错过了这些知识的人，Software Systems Architecture的第12章提供了一个起点，另外Simon Brown的著作对软件建模的介绍更新且更易于理解。
本书中未涉及的另一个基础架构实践是如何评估软件架构。该主题在我们上一本书的第6章、Software Systems Architecture的第14章和Software Architecture in Practice的第21章都有介绍。读者还可以上网搜索有关架构评估方法的信息，例如架构权衡分析方法（Architecture Tradeoff Analysis Method，ATAM）。
此外，我们还假设读者具备敏捷开发的相关知识，如敏捷、Scrum和规模化敏捷框架（Scaled Agile Framework，SAFe），因此对软件开发生命周期过程不做深入讨论，也不对DevSecOps等软件部署和操作方法做或深或浅的讨论，并且特意去除了数据库、安全性、自动化等特定技术领域的详细信息。当然，我们会在相关的地方引用这些主题，但假设读者熟悉这些知识。在上一本书《持续架构》中，我们涵盖了这些主题，但没有涉及技术细节。另外请注意，术语表中定义的术语首次出现在本书中时会以粗体突出显示。
过去几年，软件架构的基础并没有改变，架构的总体目标依然是使正在开发的软件能够尽早并持续地交付业务价值。不幸的是，许多架构从业者并不会优先考虑这个目标，甚至不理解这个目标。
我们三人称自己为架构师，因为我们相信日常工作中所做的事情至今没有更好的解释。我们曾就职于软硬件供应商、管理咨询公司和大型金融机构，主要从事软件和企业架构相关的工作。但是，当说自己是架构师时，我们觉得有必要对其进行限定，就像需要一个解释来将我们与不增加任何价值的IT架构师的刻板印象区分开来。读者可能比较熟悉这样一种表达方式：“我是一名架构师，但我也交付、编写代码，与客户打交道 （填写你认为有价值的活动）。”
不管怎样，我们相信，表现出抽象派疯狂科学家、技术工匠或演讲狂人等品质的架构师只是少数从业者。作为软件交付团队的一部分，大多数架构师能够有效地工作，很多时候甚至可能不自居为架构师。实际上，无论你理解与否，所有软件都有一个架构，且大部分软件产品都会有一小组高级开发人员来创建一个可行的架构，而不论这个架构是否被记录下来。因此，最好将架构视为一种技能而非一种角色。
我们相信时代已经永久地摆脱了先前以文档为中心的软件架构实践，或许也已经摆脱了传统的企业架构。然而，根据经验，我们一致认为仍然需要一种架构方法，涵盖敏捷、持续交付、DevSecOps和云计算，并从架构的宏观视角将这些方法集成起来，并按照业务优先级进行需求交付。本书旨在解释这种我们称为持续架构的方法，并展示如何在实践中有效地利用这种方法。
《持续架构》主要是对概念、思想和工具进行概述和讨论，而本书则提供了更多基于实践的建议，侧重于指导读者如何利用持续架构方法，并涵盖了有关安全性、性能（performance）、可伸缩性、弹性、数据和新兴技术等主题的深入且最新的信息。
我们重新审视了架构在敏捷、DevSecOps、云和以云为中心的平台中的作用，也为技术人员提供了一份实用指南，指导他们通过不断更新经典软件架构实践的方式来应对当今应用程序所面临的一些复杂挑战。我们还重新审视了软件架构的一些核心主题：架构师在开发团队中的角色；如何满足软件涉众的质量属性需求；架构在实现如安全性、可伸缩性、性能和弹性等关键交叉需求方面的重要性。对上述每个领域，我们都提供了使架构实践有意义的一种新方法，这种方法通常建立在上一代软件架构相关书籍给出的传统建议之上，并解释了如何在现代软件开发环境中应对这些领域的挑战。
本书的结构如下：
第1章提供场景，定义术语，并概述在每章都会使用的案例研究（附录A包含了有关案例研究的详细信息）。
第2章列出我们的主要思想，希望读者了解如何在当今的软件开发环境中开展架构工作。
第3～7章探讨对现代应用程序开发来说至关重要的相关架构主题：数据、安全性、可伸缩性、性能和弹性。我们解释软件架构方法，尤其是持续架构方法，探讨如何在解决各个架构问题的同时保持敏捷的工作方式，以持续地向生产环境交付变更。
第8章和第9章主要着眼于未来，讨论架构在处理新兴技术方面的作用，并总结当今敏捷和DevOps时代下架构实践遇到的挑战以及应对这些挑战的一些潜在方法。
我们希望想成为软件架构师的读者了解该领域的经典基础知识（可能来自Software Architecture in Practice或Software Systems Architecture之类的书籍），同时认识到需要更新方法以应对当今快速发展的软件开发环境所带来的挑战。想要了解架构和设计的软件工程师也可能会被书中实用的、面向交付的重点内容所吸引。
为了使本书只涉及必要的内容并专注于上一本书以来发生的变化，我们假设读者已经熟悉包括信息安全、云计算、基于微服务的架构以及常见的自动化技术（例如自动化测试和部署流水线）在内的主流技术基础知识。我们希望读者熟悉架构设计的基本方法，了解如何创建软件的可视化模型以及领域驱动设计（Domain-Driven Design，DDD）等相关方法。如果读者对架构设计基础没有把握，我们建议从定义明确的方法开始，例如软件工程研究所的属性驱动设计或其他更简单的方法（如Software Systems Architecture第7章中概述的方法）。虽然软件建模被忽视了几年，但似乎正在重新回归主流实践。对于一开始错过了这些知识的人，Software Systems Architecture的第12章提供了一个起点，另外Simon Brown的著作对软件建模的介绍更新且更易于理解。
本书中未涉及的另一个基础架构实践是如何评估软件架构。该主题在我们上一本书的第6章、Software Systems Architecture的第14章和Software Architecture in Practice的第21章都有介绍。读者还可以上网搜索有关架构评估方法的信息，例如架构权衡分析方法（Architecture Tradeoff Analysis Method，ATAM）。
此外，我们还假设读者具备敏捷开发的相关知识，如敏捷、Scrum和规模化敏捷框架（Scaled Agile Framework，SAFe），因此对软件开发生命周期过程不做深入讨论，也不对DevSecOps等软件部署和操作方法做或深或浅的讨论，并且特意去除了数据库、安全性、自动化等特定技术领域的详细信息。当然，我们会在相关的地方引用这些主题，但假设读者熟悉这些知识。在上一本书《持续架构》中，我们涵盖了这些主题，但没有涉及技术细节。另外请注意，术语表中定义的术语首次出现在本书中时会以粗体突出显示。
过去几年，软件架构的基础并没有改变，架构的总体目标依然是使正在开发的软件能够尽早并持续地交付业务价值。不幸的是，许多架构从业者并不会优先考虑这个目标，甚至不理解这个目标。
我们三人称自己为架构师，因为我们相信日常工作中所做的事情至今没有更好的解释。我们曾就职于软硬件供应商、管理咨询公司和大型金融机构，主要从事软件和企业架构相关的工作。但是，当说自己是架构师时，我们觉得有必要对其进行限定，就像需要一个解释来将我们与不增加任何价值的IT架构师的刻板印象区分开来。读者可能比较熟悉这样一种表达方式：“我是一名架构师，但我也交付、编写代码，与客户打交道 （填写你认为有价值的活动）。”
不管怎样，我们相信，表现出抽象派疯狂科学家、技术工匠或演讲狂人等品质的架构师只是少数从业者。作为软件交付团队的一部分，大多数架构师能够有效地工作，很多时候甚至可能不自居为架构师。实际上，无论你理解与否，所有软件都有一个架构，且大部分软件产品都会有一小组高级开发人员来创建一个可行的架构，而不论这个架构是否被记录下来。因此，最好将架构视为一种技能而非一种角色。
我们相信时代已经永久地摆脱了先前以文档为中心的软件架构实践，或许也已经摆脱了传统的企业架构。然而，根据经验，我们一致认为仍然需要一种架构方法，涵盖敏捷、持续交付、DevSecOps和云计算，并从架构的宏观视角将这些方法集成起来，并按照业务优先级进行需求交付。本书旨在解释这种我们称为持续架构的方法，并展示如何在实践中有效地利用这种方法。
媒体评论
“我一直为这几位作者乐于分享的精神感到高兴，且深受鼓舞。他们的第一本书为理解如何演进软件密集型系统架构奠定了基础，而这本书在第一本书的基础上增加了一些非常可行的方法。”
—— Grady Booch，IBM 研究院软件工程首席科学家
更新架构实践，以应对新的挑战、环境和人们的期望
三位作者有着丰富的软件架构经验，并将这些经验应用于现实环境中的具体软件架构实践。本书为在现实环境中使用持续架构方法提供了实践指南，并阐明了架构在敏捷、DevOps和云平台时代不断变化的角色。
本书使架构师和软件工程师能够快速应用面向交付的知识，提供了解决当今软件系统关键质量属性和交叉问题（例如安全性、性能、可伸缩性、弹性、数据和新兴技术等）的深入指导。通过一个贯穿全书的案例研究，对每项关键技术都进行了演示，反映了作者应对复杂软件环境的丰富经验。关键主题包括：
创建可持续且具有连贯性的软件系统，系统满足功能需求和相关涉众关心的质量属性。
将基于团队的软件架构和架构方法理解为“决策流”。
总结数据管理、集成和变更的关键问题，以及各种数据技术对软件架构的影响。
面向安全性的软件架构，包括持续性的风险建模和缓解风险。
面向可伸缩性和弹性的软件架构，包括微服务和serverless架构环境下的缩放。
使用软件架构方法来提高持续交付环境中的系统性能。
使用软件架构方法来成功地应用新兴技术。
—— Grady Booch，IBM 研究院软件工程首席科学家
更新架构实践，以应对新的挑战、环境和人们的期望
三位作者有着丰富的软件架构经验，并将这些经验应用于现实环境中的具体软件架构实践。本书为在现实环境中使用持续架构方法提供了实践指南，并阐明了架构在敏捷、DevOps和云平台时代不断变化的角色。
本书使架构师和软件工程师能够快速应用面向交付的知识，提供了解决当今软件系统关键质量属性和交叉问题（例如安全性、性能、可伸缩性、弹性、数据和新兴技术等）的深入指导。通过一个贯穿全书的案例研究，对每项关键技术都进行了演示，反映了作者应对复杂软件环境的丰富经验。关键主题包括：
创建可持续且具有连贯性的软件系统，系统满足功能需求和相关涉众关心的质量属性。
将基于团队的软件架构和架构方法理解为“决策流”。
总结数据管理、集成和变更的关键问题，以及各种数据技术对软件架构的影响。
面向安全性的软件架构，包括持续性的风险建模和缓解风险。
面向可伸缩性和弹性的软件架构，包括微服务和serverless架构环境下的缩放。
使用软件架构方法来提高持续交付环境中的系统性能。
使用软件架构方法来成功地应用新兴技术。
