在 2015 年的 OSCON 上，我做了一个关于架构是什么以及为什么重要的简短演讲（14 分钟）。
软件架构指南
当软件行业的人谈论“架构”时，他们指的是对软件系统内部设计最重要方面的模糊定义。良好的架构非常重要，否则将来添加新功能会变得越来越慢和昂贵。
像软件领域的许多人一样，我一直对“架构”一词持谨慎态度，因为它通常暗示着与编程的分离和不健康的浮夸。但我通过强调良好的架构是支持自身发展的东西，并且与编程紧密相连来解决我的担忧。我的职业生涯大部分时间都在围绕着以下问题：好的架构是什么样的，团队如何创建它，以及如何在我们的开发组织中最好地培养架构思维。此页面概述了我对软件架构的看法，并向您介绍了本网站上有关架构的更多资料。
martinfowler.com 上有关软件架构的资料指南。
什么是架构？
软件领域的人们长期以来一直在争论架构的定义。对某些人来说，它类似于系统的基本组织，或者最高级别组件连接在一起的方式。我对这一点的思考是通过与 Ralph Johnson 的电子邮件交流形成的，他质疑这种说法，认为没有客观的方法来定义什么是基本的或高级别的，并且对架构的更好理解是专家开发人员对系统设计的共同理解。
Ralph Johnson 在 QCon 上发言
架构的第二种常见定义风格是它是“需要在项目早期做出的设计决策”，但 Ralph 也抱怨这一点，说它更像是你希望在项目早期就能做出的决策。
他的结论是“架构是关于重要的事情。无论那是什么”。乍一看，这听起来很老套，但我发现它包含了很多丰富的内容。这意味着，从架构角度思考软件的核心是决定什么是重要的（即什么是架构的），然后将精力花在保持这些架构元素处于良好状态。为了让开发人员成为架构师，他们需要能够识别哪些元素是重要的，识别哪些元素如果不受控制可能会导致严重问题。
Ralph 的电子邮件构成了我为IEEE 软件撰写的专栏的核心，该专栏讨论了软件架构的含义和架构师的角色。
为什么架构很重要？
对于软件产品的客户和用户来说，架构是一个棘手的主题——因为它不是他们立即就能感知到的东西。但是糟糕的架构是导致代码腐烂增长的主要因素——软件中的这些元素阻碍了开发人员理解软件的能力。包含大量代码腐烂的软件更难修改，导致功能交付速度更慢，缺陷更多。
这种情况与我们通常的经验相反。我们习惯于将“高质量”的东西视为成本更高的东西。对于软件的某些方面，例如用户体验，这可能是正确的。但是，当涉及架构和内部质量的其他方面时，这种关系就会颠倒过来。高的内部质量可以更快地交付新功能，因为阻碍的代码腐烂更少。
虽然在短期内，在代码腐烂的影响产生之前，我们可以为了更快的交付速度而牺牲质量，但人们低估了代码腐烂导致整体交付速度变慢的速度。虽然这无法客观衡量，但经验丰富的开发人员认为，关注内部质量在几周而不是几个月内就会得到回报。
应用程序架构
软件开发中的重要决策因我们考虑的上下文的规模而异。一个常见的规模是应用程序的规模，因此称为“应用程序架构”。
定义应用程序架构的第一个问题是没有明确定义什么是应用程序。我的观点是应用程序是一种社会建构
- 开发人员视为单个单元的一组代码
- 业务客户视为单个单元的一组功能
- 有钱人视为单个预算的举措
如此宽松的定义导致应用程序的潜在规模多种多样，从几个人到几百人的开发团队不等。（你会注意到，我将规模视为参与的人数，我认为这是衡量此类事情的最有用的方法。）这与企业架构的关键区别在于，围绕社会建构存在很大程度的统一目标。
应用程序边界
软件开发中尚未解决的问题之一是确定一段软件的边界是什么。（浏览器是操作系统的一部分吗？）许多面向服务架构的支持者认为应用程序正在消失——因此未来的企业软件开发将是关于将服务组装在一起。
我不认为应用程序会消失，原因与应用程序边界如此难以划定的原因相同。本质上，应用程序是社会建构
微服务指南
微服务架构模式是一种将单个应用程序开发为一组小型服务的方法，每个服务都在自己的进程中运行，并使用轻量级机制进行通信，通常是 HTTP 资源 API。这些服务围绕业务功能构建，可以通过全自动部署机制独立部署。对这些服务的集中管理极少，这些服务可以用不同的编程语言编写，并使用不同的数据存储技术。虽然它们的优势使它们在过去几年中非常流行，但它们也带来了增加分布、降低一致性和需要运营管理成熟度的成本。
无服务器架构
无服务器架构是结合了第三方“后端即服务”(BaaS) 服务和/或包含在“函数即服务”(FaaS) 平台上的托管、临时容器中运行的自定义代码的应用程序设计。通过使用这些想法以及单页应用程序等相关想法，此类架构消除了对传统始终在线服务器组件的大部分需求。无服务器架构可能会受益于显着降低的运营成本、复杂性和工程交付周期，但代价是增加了对供应商依赖性的依赖以及相对不成熟的支持服务。
微前端
好的前端开发很难。扩展前端开发以使许多团队能够同时在一个大型复杂产品上工作则更加困难。在本文中，我们将描述最近将前端整体拆分为许多更小、更易于管理的部分的趋势，以及这种架构如何提高处理前端代码的团队的效率和效益。除了讨论各种优势和成本之外，我们还将介绍一些可用的实现选项，并且我们将深入研究一个完整的示例应用程序来演示该技术。
GUI 架构
在 2000 年代中期，我正在进行几个可能变成书籍的写作项目，但尚未完成。其中一个是关于用户界面的架构。作为这项工作的一部分，我起草了一份关于 GUI 架构如何演变的描述，将表单和控件的默认方法与模型-视图-控制器 (MVC) 模式进行了比较。MVC 是软件领域中最容易被误解的模式之一，这是可以理解的，因为它没有得到很好的记录。所以我的这篇文章试图更好地描述 MVC 的真正含义，以及它是如何通过模型-视图-表示器和其他形式演变的。
表示域数据分层
模块化信息丰富的程序最常见的方法之一是将其分为三个广泛的层：表示层（UI）、域逻辑层（又称业务逻辑层）和数据访问层。因此，您经常会看到 Web 应用程序分为了解如何处理 HTTP 请求和呈现 HTML 的 Web 层、包含验证和计算的业务逻辑层，以及整理如何管理数据库或远程服务中的持久数据的数据库访问层。
分布式系统模式目录
分布式系统对程序提出了特殊的挑战。它们通常要求我们拥有多个数据副本，这些副本需要保持同步。然而，我们不能依赖处理节点可靠地工作，网络延迟很容易导致不一致。尽管如此，许多组织仍然依赖于一系列核心分布式软件来处理数据存储、消息传递、系统管理和计算能力。这些系统面临着共同的问题，并且它们使用类似的解决方案来解决这些问题。2020 年，Unmesh Joshi 开始收集这些解决方案作为模式，并在开发过程中将它们发布在本网站上。2023 年，这些模式被收录在《分布式系统模式》一书中。此页面链接到每个模式的简要摘要，并提供指向 oreilly.com 上在线电子书出版物中相关章节的深层链接
功能切换（又称功能标志）
功能切换（通常也称为功能标志）是一种强大的技术，允许团队在不更改代码的情况下修改系统行为。它们属于各种使用类别，在实现和管理切换时必须考虑这种分类。切换会引入复杂性。我们可以通过使用智能切换实现实践和适当的工具来管理我们的切换配置来控制这种复杂性，但我们也应该致力于限制系统中切换的数量。
使用已建立的 UI 模式模块化 React 应用程序
尽管已确立的 UI 模式在解决 UI 设计中的复杂问题方面已被证明是有效的，但在前端开发领域，它们常常被忽视。本文探讨了已确立的 UI 构建模式在 React 世界中的应用，并通过一个重构代码示例展示了其优势。重点介绍了分层架构如何帮助组织 React 应用程序，以提高响应能力和适应未来的变化。
企业架构
应用程序架构专注于某种概念性应用程序边界内的架构，而企业架构则着眼于大型企业的整体架构。这类组织通常规模庞大，无法将所有软件归类到任何 cohesive 的分组中，因此需要跨团队协调，这些团队拥有多个代码库，彼此独立开发，资金和用户也独立运作。
企业架构的很大一部分是了解哪些事情值得付出集中协调的成本，以及应该采取何种形式的协调。一种极端情况是，一个中央架构小组必须批准企业中每个软件系统的所有架构决策。这样的团队会减缓决策速度，并且无法真正了解如此广泛的系统组合中的问题，从而导致决策不佳。但另一种极端情况是根本没有协调，导致团队重复工作，不同系统无法互操作，以及团队之间缺乏技能发展和交叉学习。
与大多数具有敏捷思维的人一样，我更倾向于去中心化，因此宁愿靠近混乱的岩石，也不愿窒息控制。但站在这边的同时，我们仍然需要避开岩石，并找到一种方法，在最大限度地减少实际成本的情况下，最大限度地提高本地决策。
企业架构师加入团队
企业架构团队经常与日常开发脱节。这会导致他们对开发工作的了解过时，而开发团队也没有从公司全局的角度考虑问题。我的同事（Thoughtworks 首席技术官）Rebecca 经常看到这种情况发生，她认为企业架构师可以通过加入开发团队来提高效率。
制定整合的业务和技术战略
为了有效利用技术，我们需要将技术思维与基础业务计划保持一致。技术战略可以推动这种一致性，前提是它能恰当地整合业务和技术。我们开发了一个概念框架来帮助我们进行这种战略思考，该框架基于对战略举措共同方面的认识，引导我们确定了 11 个普遍的战略方向。对于每个方向，我们都概述了它们提出的关键业务问题，以及我们需要进行的调查，以探索技术影响。我们发现，这个框架不仅能带来更有效的技术战略，还能让技术为业务思考提供信息，开发新的收入来源。
产品优于项目
软件项目是资助和组织软件开发的一种流行方式。它们将工作组织成临时的、仅构建的团队，并通过商业案例中预测的特定收益获得资金。而产品模式则使用持久的、构思-构建-运行的团队来处理持续的业务问题。产品模式允许团队快速调整方向，缩短端到端周期时间，并允许在保持软件架构完整性以保持其长期有效性的同时，使用短周期迭代来验证实际收益。
架构师电梯 - 参观高层
许多大型组织的 IT 引擎与行政顶层办公室之间隔着许多层楼，这也将业务和数字战略与其执行的重要工作分离开来。架构师的主要职责是在顶层办公室和机房之间乘坐电梯，在需要支持这些数字工作的地方停下来：自动化软件制造，最大限度地减少前期决策，以及随着技术发展影响组织。
企业架构师在精益企业中的作用
当一个组织采用敏捷思维时，企业架构不会消失，但企业架构师的角色会发生变化。企业架构师不再做选择，而是帮助其他人做出正确的选择，然后传播这些信息。企业架构师仍然需要形成愿景，但随后需要在团队之间搭建桥梁，以建立学习型社区。这将使团队能够探索新方法并相互学习，而企业架构师则是这种成长中的合作伙伴。
使用 REST 进行企业集成
大多数内部 REST API 都是为单个集成点专门构建的一次性 API。在本文中，我将讨论非公共 API 的限制和灵活性，以及在多个团队之间进行大规模 RESTful 集成所吸取的教训。