“软件架构师”在全球众多优秀职业排行榜都排最前面的位置。但是，当读者查看这些职业清单上的其他工作（例如护士或财务经理）时，他们都有一条明确的职业发展路径。为什么软件架构师没有清晰的定义呢？

首先，行业对软件架构本身没有很好的定义。当我们教授基础课程时，学生们希望对软件架构师的工作做一个明确的定义，但是我们坚决拒绝给出这样的定义。而且我们不是唯一这样做的，著名的架构师马丁·福勒（Martin Fowler）在他著名的白皮书“谁需要架构师？”中也拒绝尝试定义它，而是给了一句著的名言：

不管怎么样，架构是很重要的东西……。

——拉尔夫·约翰逊

接下来，我们创建了如图1-1所示的思维导图，该思维导图虽然不完整，但却明确了软件架构的范围。事实上，我们很快也提供我们对软件架构的定义。

其次，如思维导图所示，软件架构师的角色体现了数量和责任范围的不断扩大。十年前，软件架构师仅处理架构的纯技术方面，例如模块化，组件和模式。当前，由于广泛的功能采用了的新架构（如微服务）样式，软件架构师的作用得到了扩展。我们在“ Intersection of Architecture and…”中涵盖了架构师的许多交叉点和组织的其余部分。

图1-1。软件架构师的职责包括技术能力，软技能，战略意识以及许多其他能力

第三，由于快速发展的软件开发生态，软件架构目标是一个不断变化和发展的。今天提出的任何定义在几年后都将无可救药地过时，淘汰。软件架构定义维基百科虽然提供了合理的概述，但是许多陈述已经过时，例如“软件架构是当时做出的基本的架构选择，一旦实施，更改成本很高。” 但是，架构师以内置增量的想法设计了诸如微服务之类的现代架构风格，在微服务中进行架构变更不再昂贵。当然，该能力意味着需要权衡其他问题，例如耦合，许多有关软件架构的书籍将其视为静态问题。一旦解决，我们就可以放心地忽略它。但是，我们在整本书中都认识到软件架构固有的动态特性，包括软件架构定义本身。

第四，有关软件架构的许多材料仅仅具有历史意义。Wikipedia页面的读者不会注意到令人困惑的首字母缩略词和对整个知识领域的相互引用。但是，许多首字母缩略词表示过时或失效。即使几年前完全有效的解决方案现在已经无法使用，因为应用的上下文已发生改变。软件架构的历史充斥着架构师过去尝试过的事情，只会考虑到了当时的一些不利因素。我们在本书中涵盖了许多这些课程去讨论它们。

为什么现在要写一本关于软件架构基础的书？软件架构的范畴并不是研发领域中唯一不断变化的因素。新技术，新工艺，新能力……实际上找到过去十年未发生变化的事情比列出所有变化要容易得多。软件架构师必须在这些不断变化的生态系统中做出决策。因为一切都在变化，包括我们做出决策的基础，所以架构师应该重新检查一些核心公理，这些公理可以在早先撰写有关软件架构的文章中找到。例如，关于软件架构的较早书籍没有考虑DevOps的影响，因为在编写这些书时还不存在。

在学习软件架构时，读者必须记住，就像许多艺术一样，它只能在上下文中理解。架构师做出的许多决策都是基于他们所处环境的现实情况。例如，20世纪后期架构的主要目标之一就是最有效地利用共享资源，因为当时所有的基础设施都是昂贵且商业化：操作系统、应用程序服务器、数据库服务器等。想象一下，我们走进2002年的数据中心并告诉运维负责人：“嘿，我对革命性的架构有一个很好的主意，其中每种服务都在自己的隔离机器上运行，并拥有自己的专用数据库（描述了我们现在所知道的微服务）。因此，这意味着我将需要50个Windows许可证，另外30个应用服务器许可证和至少50个数据库服务器许可证。” 在2002年，尝试构建这种微服务的架构将是非常昂贵的。然而，随着最近几年开源的出现，再加上DevOps革命带来的最新工程实践，我们可以合理地构建上述架构。读者应记住，所有架构不管怎么样都是其上下文的产物。

定义软件架构

整个行业有努力精确地定义“软件架构”。一些架构师将软件架构称为系统的蓝图，而另一些架构师则将其定义为开发系统的路线图。这些通用定义的目的是为了解蓝图或路线图实际包含的内容。例如，当架构师分析架构时会分析什么？

图1-2说明了一种思考软件架构的方法。在此定义中，软件架构由系统的结构（表示为支持架构的粗黑线），支持的架构特征 （“-ilities”），架构决策以及最终的设计原理组成。

图1-2。架构由系统架构特征（“ -ilities”），架构决策和设计原则的结构组成

如图1-3所示，系统的结构指的是实现系统的架构样式的类型（例如，微服务，分层或微内核）。但仅通过结构来描述架构不能完全阐明架构。例如，假设要求架构师描述一个架构，并且该架构师回答“这是一个微服务架构”。在这里，架构师只是在谈论系统的结构，而不是在谈论系统的架构。为了充分理解系统的架构，还需要了解架构特征，架构决策和设计原理。

图1-3。系统结构是指系统中使用的架构样式的类型

架构特征是定义软件架构的另一个维度（请参见图1-4）。架构特征定义了系统的成功标准，该标准通常与系统的功能正交。请注意，列出的所有特征都不需要了解系统功能，但是它们是使系统正常运行所必需的。架构特性非常重要，因此我们在本书中专门花了几章来理解和定义它们。

图1-4。架构特征是指系统必须支持的“ -ilities”

下一个定义软件架构的因素是架构决策。架构决策定义了应如何构建系统的规则。例如，架构师可能会做出架构决策，仅仅只有分层架构中的业务层和服务层才能访问数据库（请参见图1-5），从而限制了表示层对数据库直接调用。架构决策形成系统的约束，并指导开发团队确定哪些是被允许的，哪些是不允许的。

图1-5。架构决策是构建系统的规则

如果由于某种条件或其他约束而无法在系统的某个部分中实施特定的架构决策，则可以通过方差的方法打破该决策（或规则）。大多数组织都有架构审查委员会（ARB）或首席架构师使用的差异模型。这些模型将寻求与特定标准或架构决策的差异的过程形式化。ARB将分析特定架构决策的例外情况（如果没有ARB，则由首席架构师进行分析），并根据理由和权衡取舍批准或拒绝该例外情况。

系统设计定义中的最后一个因素是设计原则。设计原则与架构决策的不同之处在于，设计原则是一个准则，而不是一成不变的规则。例如，图1-6所示的设计原则指出，开发团队应利用微服务架构中服务之间的异步消息传递来提高性能。架构决策（规则）不可能涵盖服务之间通信的所有条件和选项，因此可以使用设计原则为首选方法（在这种情况下为异步消息传递）提供指导，允许开发人员选择更合适的特定情况下的通信协议（例如REST或gRPC）。

图1-6。设计原则是构建系统的准则

架构师的期望

定义软件架构师的角色与定义软件架构一样困难。它的范围从专家级程序员到定义公司的战略技术方向的CTO。我们建议不要将时间浪费定义角色的傻瓜事情上，而是建议着眼于架构师的期望。

与给定的角色，职务或职位描述无关，对软件架构师有八项核心期望：

制定架构决策

持续分析架构

紧跟最新趋势

确保遵守决策

不断的实践和经验

丰富的业务领域知识

具备人际交往能力

了解和驾驭政治

实现软件架构师角色的有效性和成功的首要关键取决于对这些期望的理解和实践。

制定架构决策

架构师定义用于指导团队，部门或整个企业中的技术决策的架构决策和设计原则。

指导是这第一个期望中的关键词。架构师应该指导而不是指定技术选择。例如，架构师可能会决定使用React.js进行前端开发。在这种情况下，架构师将做出技术决策，而不是架构决策或设计原则来帮助开发团队做出选择。架构师应该指示开发团队使用基于响应的框架进行前端Web开发，从而指导开发团队在Angular，Elm，React.js，Vue或其他任何基于响应的Web框架之间进行选择。

通过架构决策和设计原则来指导技术选择非常困难。做出有效的架构决策的关键是询问架构决策是否有助于指导团队做出正确的技术选择，或者架构决策是否为他们做出技术选择。也就是说，架构师有时可能需要做出特定的技术决策，以保留特定的架构特征，例如可伸缩性，性能或可用性。在这种情况下，他指定了特定的技术，在这里仍将被视为架构决策。架构师经常在寻找正确的路线时遇到困难，因此第19章完全涉及架构决策。

持续分析架构

期望架构师不断分析架构和当前技术环境，然后提出改进建议。

对架构师的这种期望指的是架构活力，该架构评估了随着业务和技术的变化，三年前或更多年前定义的架构在当今的可行性。根据我们的经验，没有架构师将足够的精力集中在分析现有架构上。结果，大多数架构都会经历架构衰减的因素，这种架构衰减在开发人员进行可能影响所需架构特征（例如性能，可用性和可伸缩性）的编码或设计更改时发生的。

当应用发布到是测试和发布环境，架构师经常遗忘掉这种期望。敏捷的代码修改有明显的好处，但是如果团队需要数周的时间来测试变更，而花费数月的时间来发布，那么架构师将无法在整个架构中实现敏捷。

架构师必须从整体上分析技术和问题领域的变化，以确定架构的合理性。尽管这种考虑很少出现在工作发布中，但架构师必须满足这一期望，以保持应用程序的相关性。

紧跟最新趋势

架构师将紧跟最新技术和行业趋势。

开发人员必须及时了解他们每天使用的最新技术，以保持相关性（并保持工作有效性）。架构师对保持最新技术和行业趋势的要求甚至更高。架构师做出的决定往往是持久的，并且难以更改。了解和遵循关键趋势可帮助架构师为未来做好准备并做出正确的决定。

跟踪趋势并及时了解这些趋势非常困难，特别是对于软件架构师而言。在第24章中，我们讨论了有关如何执行此操作的各种技术和资源。

确保遵守决策

架构师确保遵守架构决策和设计原则。

确保合规性意味着架构师不断验证开发团队是否遵循架构师定义，记录和沟通的架构决策和设计原则。考虑以下场景：架构师决定将对分层架构中的数据库的访问限制为仅业务和服务层（而不是表示层）。这意味着表示层必须遍历架构的所有层，才能进行最简单的数据库调用。用户界面开发人员可能会不同意此决定，并出于性能原因直接访问数据库（或持久层）。但是，架构师之所以做出该架构决策，是出于以下特定原因：控制变更。通过关闭图层，可以在不影响表示层的情况下进行数据库更改。通过不确保遵守架构决策，可能会发生类似的违规行为，架构将无法满足所需的架构特征（“ -ilities”），并且应用程序或系统将无法按预期运行。

在第6章中，我们将讨论更多有关使用自动适应性功能和自动化工具来衡量合规性的信息。

不断的实践和经验

架构师应具有多种多样的技术，框架，平台和环境。

这种期望并不意味着架构师必须是每个框架，平台和语言的专家，而是架构师至少必须熟悉各种技术。如今，大多数环境都是异构的，并且架构师至少应知道如何与多个系统和服务交互，而与这些系统或服务所使用的语言，平台和技术无关。

掌握此期望的最佳方法之一是让架构扩展其舒适区域。仅专注于单一技术或平台是一个避风港。一个有效的软件架构师应积极寻找机会，以获取多种语言，平台和技术的经验。掌握这一期望的一个好方法是专注于技术广度而不是技术深度。技术上的广度包括您所了解的但不是详细的内容，以及您所了解的很多内容。例如，对于一名架构师来说，熟悉10种不同的缓存产品以及每种缓存产品的利弊远比成为其中的一种专家更有价值。

丰富的业务领域知识

架构师应具备一定水平的业务领域专业知识。

有效的软件架构师不仅了解技术，而且了解问题空间的业务领域。 没有业务领域知识，就很难理解业务问题，目标和要求，从而难以设计出有效的架构来满足业务要求。想象一下，在一家大型金融机构担任架构师，并且不了解常见的财务术语，例如平均定向指数，临时合同，利率反弹甚至是非优先债务。没有这些知识，架构师将无法与利益相关者和业务用户进行交流，并且会很快失去信誉。

我们认识的最成功的架构师是那些具有广泛的动手技术知识以及对特定领域的丰富知识的架构师。这些软件架构师能够使用这些利益相关者所了解和理解的领域知识和语言，与C级高管和业务用户进行有效的沟通。反过来，这使软件构架人员知道他们在做什么并且有能力创建有效且正确的架构，这使他们充满了信心。

具备人际交往能力

架构师应具备出色的人际交往能力，包括团队合作，促进和领导才能。

对于大多数开发人员和架构师而言，拥有出色的领导才能和人际交往能力是一项艰巨的任务。正如技术人员，开发人员和架构师喜欢解决技术问题，而不是解决人员问题。但是，正如杰拉尔德·温伯格（Gerald Weinberg）所说的那样，“无论他们怎么说，这总是一个人的问题。” 架构师不仅要向团队提供技术指导，而且还要领导开发团队完成架构的实施。领导技能至少是成为一名有效的软件架构师所需的一半，而无论该架构师所扮演的角色或职位如何。

该行业充斥着软件架构师，所有人都在争夺数量有限的架构职位。拥有强大的领导才能和人际交往能力是架构师与其他架构师区分开来并在人群中脱颖而出的好方法。我们认识许多软件架构师，他们都是优秀的技术专家，但由于无法领导团队，教练和指导者开发人员，无法有效地交流思想，架构决策和原则，因此是无效的架构师。不用说，那些架构师很难担任职位或工作。

了解和驾驭政治

架构师了解企业的​​政治氛围，并能够驾驭政治。

关于谈判和推动办公室政治的说法似乎很奇怪关于一本软件架构的书。为了说明谈判技巧多么重要和必要，请考虑以下场景：开发人员决定利用策略模式来降低特定复杂代码的整体循环复杂性。谁真正在乎？可能会为开发人员使用这种模式而鼓掌，但是在几乎所有情况下，开发人员都无需寻求此类决策的批准。

现在考虑以下情形：负责大型客户关系管理系统的架构师在控制来自其他系统的数据库访问，保护某些客户数据以及更改任何数据库架构方面存在问题，因为太多其他系统正在使用CRM数据库。因此，架构师决定创建所谓的应用程序孤岛，其中只能从拥有该数据库的应用程序访问每个应用程序数据库。做出此决定将使架构师更好地控制客户数据，安全性和变更控制。但是，与以前的开发人员情况不同，该决定也将受到公司中几乎每个人的挑战（当然，CRM应用程序团队可能会例外）。其他应用程序需要客户管理数据。如果这些应用程序不再能够直接访问数据库，则它们现在必须向CRM系统询问数据，从而需要通过REST，SOAP或某些其他远程访问协议进行远程访问。

要点是，几乎架构师的每个决策都会受到挑战。由于成本增加或工作量（时间）增加，产品所有者，项目经理和业务利益相关者将面临架构决策的挑战。感觉自己的方法更好的开发人员也将挑战架构决策。无论哪种情况，架构师都必须了解公司的政治状况，并运用基本的谈判技巧来使大多数决定获得批准。对于软件架构师来说，这一事实可能非常令人沮丧，因为作为开发人员做出的大多数决策都不需要批准甚至不需要审查。诸如代码结构，类设计，设计模式选择，有时甚至是语言选择之类的编程方面都是编程艺术的一部分。但是，现在，架构师终于能够做出广泛而重要的决定，必须为几乎所有这些决定辩护并为之奋斗。谈判技巧（如领导技巧）是如此关键和必要，以至于我们在本书的整个章节中都专门用来理解它们（请参阅第23章）。

架构之间的交集

在过去的十年中，软件架构的范围不断扩大，以包含越来越多的责任和观点。十年前，架构与运营之间的典型关系是合同的和正式的，并带有很多官僚主义。大多数公司为了避免托管自己的业务的复杂性，经常将业务外包给第三方公司，并承担服务级别协议的合同义务，例如正常运行时间，规模，响应能力以及许多其他重要的架构特征。现在，诸如微服务之类的架构可以自由地利用以前仅用于操作的问题。例如，弹性规模曾经很痛苦地内置到架构中（请参阅第15章），而微服务通过架构师和DevOps之间的联系来轻松地处理它。

历史：PETS.COM以及为什么我们有弹性规模

软件开发的历史包含很多教训，无论是好是坏。我们假设当前的功能（例如弹性标度）是由于某个聪明的开发人员而在一天之内出现的，但是这些想法通常是来自艰苦的教训。Pets.com代表了汲取教训的早期例子。Pets.com出现在互联网的早期，希望成为宠物用品的Amazon.com。幸运的是，他们有一个出色的营销部门，该部门发明了一个引人注目的吉祥物：一个带有麦克风的袜子木偶，上面讲着不敬虔的话。吉祥物成为超级巨星，在游行和国家体育赛事中公开露面。

不幸的是，Pets.com的管理层显然将所有的钱都花在了吉祥物上，而不是基础设施上。一旦订单开始涌入，他们就没有准备好。网站运行缓慢，交易丢失，交货延迟等等……最糟糕的情况是。事实上，这是如此糟糕，以致该公司在灾难性的圣诞节高峰后不久就关门大吉，仅将剩余的宝贵资产（吉祥物）卖给了竞争对手。

公司需要的是弹性规模：根据需要启动更多资源实例的能力。云提供商将这种功能作为商品提供，但是在互联网的早期，公司不得不管理自己的基础架构，而且许多公司成为以前闻所未闻的现象的受害者：太多的成功会扼杀业务。Pets.com和其他类似的恐怖故事促使工程师开发了架构师现在喜欢的框架。

以下各节深入探讨了架构师的角色与组织其他部分之间的一些新交集，重点介绍了架构师的新功能和职责。

工程实践

传统上，软件架构与用于创建软件的开发过程是分开的。存在数十种流行的方法来构建软件，包括瀑布和许多敏捷的方式（比如Scrum, Extreme

Programming, Lean, and Crystal），这些方法大部分不会影响软件架构。

但是，在过去的几年中，工程技术的进步使过程对软件架构的关注更为突出。将软件开发过程与工程实践分开是很有用的。通过过程，我们指的是团队的组成和管理方式，会议的进行方式以及工作流的组织方式。它指的是人们如何组织和互动的机制。另一方面，软件工程实践是指与流程无关的实践，这些实践已说明了可重复的好处。例如，持续集成是一种行之有效的工程实践，不依赖于特定的过程。

从极限编程到持续交付的道路

极限编程（XP）的起源很好地说明了软件过程与工程之间的区别。在1990年代初期，一群经验丰富的软件开发人员由肯特·贝克（Kent Beck）领导的团队开始质疑当时流行的数十种不同的开发流程。根据他们的经验，似乎没有人创造出可重复的良好结果。XP的一位创始人表示，选择一种现存的流程“没有比掷硬币更能保证项目成功。” 他们决定重新考虑如何构建软件，并于1996年3月启动了XP项目。为了告知他们的过程，他们拒绝了常规知识，而是着重于实践导致过去的项目成功，达到了极限。他们的理由是，他们在以前的项目中看到了更多测试与更高质量之间的关联。因此，XP的测试方法将实践推到了极致：首先进行测试优先开发，确保所有代码在进入代码库之前都经过测试。

XP被归类为其他 流行的敏捷过程具有相似的观点，但这是包括工程实践（如自动化，测试，持续集成和其他基于经验的具体技术）的少数方法之一。继续推进软件开发的工程方面的工作继续在《持续交付》（Addison-Wesley Professional）一书（许多XP实践的更新版）中进行，并在DevOps运动中取得了成果。在许多方面，DevOps革命发生在运营部门采用XP最初拥护的工程实践时：自动化，测试，声明性单一事实来源等。

我们坚决支持这些进步，这些进步构成了逐步的步骤，这些步骤最终会将软件开发逐步升级为适当的工程学科。

关注工程实践很重要。首先，软件开发缺乏更成熟的工程学科的许多功能。例如，与软件架构的类似重要方面相比，土木工程师可以更准确地预测结构变化。其次，软件开发的致命弱点之一是估算-多少时间，多少资源，多少钱？这种困难的部分原因是过时的会计惯例无法适应软件开发的探索性质，但是另一部分原因是传统上我们在评估方面很差，至少部分是由于未知数。

…becauseas we know, there are known knowns; there are things we know we know. We alsoknow there are known unknowns; that is to say we know there are some things wedo not know. But there are also unknown unknowns—the ones we don’t know wedon’t know.

FormerUnited States Secretary of Defense Donald Rumsfeld

未知的未知数是软件系统的宿敌。许多项目以已知的未知数开始：开发人员必须了解他们知道即将到来的领域和技术的事情。但是，项目也成为未知未知因素的受害者。没人知道会突然出现的事情突然出现了，这就是为什么所有“大型设计”软件工作都会遭受损失的原因：架构师无法为未知的未知而设计。引用Mark（您的作者之一）：

由于未知的未知，所有架构都将变得迭代，敏捷才意识到这一点，并且会更快地做到这一点。

因此，虽然研发过程和架构设计分开，但是迭代过程更适合软件架构的性质。试图使用过时的流程（例如瀑布模式）来构建现代系统（例如微服务）的团队会发现，过时的流程会产生很大的摩擦，而忽略了软件如何结合的现实。

通常，架构师还是项目的技术负责人，因此可以确定团队使用的工程实践。正如架构师在选择架构之前必须仔细考虑问题领域一样，他们还必须确保架构风格和工程实践形成共生的网格。例如，微服务架构假设自动机器配置，自动测试和部署以及大量其他假设。试图用过时的操作团队，手动流程和很少的测试来构建这些架构之一，这将给成功带来巨大的磨擦和挑战。正如不同的问题领域适合某些架构风格一样，工程实践也具有相同的共生关系。

从极限编程到持续交付的思想演进仍在继续。工程实践的最新进展允许在架构中使用新功能。尼尔（Neal）的最新著作《演进式架构（O'Reilly）》着重介绍了思考工程实践与架构交汇点的新方法，从而实现了更好的工程管理自动化。虽然我们不会在此阐述该书，但它提供了重要的新术语和关于架构特性的思考方式，将为本书的其余部分注入灵感。尼尔（Neal）的书涵盖了构建随时间而优雅变化的架构的技术。在第4章中，我们将架构描述为需求和其他关注点的组合，如图1-7所示。

图1-7。软件系统的架构包括需求和所有其他架构特征

正如软件开发界的任何经验所表明的那样，没有什么是静态的。因此，架构师可以设计一个满足特定条件的系统，但设计必须在实现（架构师如何确保其设计正确实现）和软件开发生态系统所驱动的不可避免的变化中生存。我们需要的是一种演进式架构。

随着时间的推移发生变化，建筑进化架构引入了使用适应性功能来保护（和控制）架构特征的概念。这个概念来自进化计算。在设计遗传算法时，开发人员可以使用多种技术来更改解决方案，从而不断迭代开发新的解决方案。在针对特定目标设计此类算法时，开发人员必须衡量结果，以了解它是否与最佳解决方案更近或更远。该措施是一种健壮性功能。例如，如果开发人员设计了一种遗传算法来解决旅行推销员问题（其目标是各个城市之间的最短路线），则适应度函数将着眼于路径长度。

架构方法论采纳了这个想法来创建架构适应性功能：对某些架构特征的客观完整性评估。该评估可能包括多种机制，例如度量，单元测试，监视器和混乱工程。例如，架构师可以将页面加载时间标识为架构的重要特征。为了使系统能够在不降低性能的情况下进行更改，该架构构建了适应性功能作为测试，该功能可以测量每个页面的页面加载时间，然后将其作为项目持续集成的一部分运行测试。因此，架构师总是知道架构关键部分的状态，因为他们具有针对每个部分的适应性功能形式的验证机制。

在这里，我们将不介绍健壮性功能的全部细节。但是，我们将在适用时指出该方法的机会和示例。注意健壮性功能执行的频率与它们提供的反馈之间的相关性。您将看到采用敏捷工程实践（例如，持续集成，自动机器配置和类似实践）使构建弹性架构更加容易。它还说明了如何将架构与工程实践结合在一起。

运维/开发运维一体化

对架构方法论的一些重新思考，DevOps的出现是架构与相关领域之间最近最明显的交集。多年以来，许多公司都将运维视为与软件开发分开的功能。他们通常将运维外包给另一家公司以节省成本。在1990年代和2000年代设计的许多架构都假定架构师无法控制运维，并且围绕该限制进行防御性的构建（有关此方面的一个很好的例子，请参阅第15章中的基于空间的架构）。

但是，几年前，几家公司开始尝试将多种运维问题与该架构结合在一起的新型架构。例如，在较旧的架构中，例如ESB驱动的SOA，该架构被设计为处理诸如弹性规模之类的事情，这使该过程的架构大大复杂化。基本上，由于节省了外包业务的成本，架构师被迫围绕引入的限制进行防御性设计。因此，他们构建了可以在内部处理规模，性能，弹性和许多其他功能的架构。该设计的副作用是大大复杂的架构。

微服务架构风格的构建者意识到，架构设计可以更好地解决这些运维问题。通过在架构和运维之间建立联系，架构师可以简化设计并依靠运维来最好地处理事情。因此，实现对资源的共用会导致意外的复杂性，并且架构师和运维人员联手创建了微服务，我们将在第17章中详细介绍微服务。

过程

另一个理论认为软件架构通常与软件开发过程正交。构建软件（过程）的方式对软件架构（结构）影响很小。因此，尽管团队使用的软件开发过程对软件架构有一定影响（尤其是围绕工程实践），但从历史上看，它们大多被认为是独立的。大多数有关软件架构的书都忽略了软件开发过程，对可预测性等问题做出了虚假的假设。但是，团队开发软件的过程会影响软件架构的许多方面。例如，由于软件的性质，在过去的几十年中，许多公司都采用了敏捷开发方法。敏捷项目中的架构师可以进行迭代开发，因此可以更快地反馈决策。反过来，这又使架构师可以更积极地进行实践以及依赖反馈的其他知识。

正如Mark先前的话所言，所有架构都是迭代的。这只是时间问题。为此，我们将假设整个敏捷方法的基线，并在适当的地方标注异常。例如，由于其年龄，政治因素或其他与软件无关的缓解因素，许多单体式架构使用较旧的过程仍然很常见。

敏捷方法论发扬光大的架构的一个关键方面是重组。团队经常发现他们需要将其架构从一种模式迁移到另一种模式。例如，一个团队从整体架构开始，因为它易于引导且快速，但现在他们需要将其迁移到更现代的架构。敏捷的方法论比计划繁重的过程更好地支持这些类型的更改，这是因为紧密的持续反馈以及对诸如绞杀者模式（注：马丁福勒提出）和功能切换之类的技术的鼓励。

数据

大量正式的应用程序开发包括外部数据存储，通常以关系（或越来越多的NoSQL）数据库的形式进行。但是，很多有关软件架构的书籍仅对架构的这一重要方面进行了简要介绍。代码和数据具有共生关系：没有另一个就没有用。

数据库管理员通常与架构师一起为复杂系统构建数据架构，分析关系和重用将如何影响应用程序组合。在本书中，我们不会深入探讨这一级别的专业细节。同时，我们不会忽略外部存储的存在和依赖性。特别是，当我们谈论架构和架构量子的操作方面时（请参阅第3章），我们将包括数据库等重要的外部问题。

软件架构定律

尽管软件架构的范围几乎不可能扩大，但确实存在统一元素。作者首先通过不断地摸索来学习了软件架构第一定律：

软件架构中的所有内容都是一个折衷方案。

软件架构第一定律

对于软件架构师而言，没有什么东西是一个很好的，干净的频谱。每个决定都必须考虑许多相反的因素。

如果架构师认为他们发现了一些不平衡的东西，那么很有可能他们还没有找到平衡点。

推论1

我们用结构支架之外的术语定义软件架构，并结合原理，特征等。 架构比架构元素的组合要广泛，这反映在我们的软件架构第二定律中：

为什么比如何做更重要。

软件构架第二定律

当我们尝试保持学生在制作工作室解决方案时在车间进行的练习的结果时，作者发现了这种观点的重要性。因为练习是定时的，所以我们保留的唯一工件是表示拓扑的图。换句话说，我们捕捉到了他们如何解决问题，而不是为什么团队做出了特定选择。架构师可以查看他们不了解的现有系统，并确定架构的工作方式，但是会难以解释为什么做出某些选择与其他选择。

在整本书中，我们重点介绍了为什么架构师在做出权衡取舍之后做出某些决定。我们还将重点介绍在“架构决策记录”中捕获重要决策的良好技术。

原文参考：https://www.jianshu.com/p/ddd3eb0deb99

声明：本资料仅供学习交流严禁使用于任何商业用途！请购买正版图书：https://www.oreilly.com/library/view/fundamentals-of-software/9781492043447/cover.html

资料整理和翻译：杨传池Chris  IT老兵，人生三大爱好（爱好喝茶，喝酒和喜欢做梦）

10+年的软件研发和项目管理经验；

7+年大型房产信息化、数字化咨询经验；

50+人以上研发团队管理，擅长团队管理和人才梯队建设；

熟悉研发管理、工程构建、体系建设、DevOps和领域建模，掌握IT研发价值链和工具链。