软件架构指南

【注】本文节译自： Software Architecture Guide (martinfowler.com)
  当软件行业的人们谈论“架构”时，他们指的是软件系统内部设计最重要方面的一个模糊定义概念。好的架构很重要，否则将来增加新功能会变得越来越慢，而且成本更高。

  像软件世界中的许多人一样，我一直对“架构”一词持谨慎态度，因为它通常暗示着与编程的分离和不健康的浮夸。但是，我通过强调好的架构可以支持其自身的发展，并与编程紧密地交织在一起，来解决我的担忧。我的职业生涯大部分时间都围绕着以下问题：好的架构是什么样的，团队如何创建它，以及如何最好地在我们的开发组织中培养架构思维。该页面概述了我对软件架构的看法，并在这个网站上有关为你带来更多关于架构的材料。martinfowler.com 上有关软件体系结构的材料指南。
马丁·福勒
2019年8月1日

什么是架构?

  软件界的人们长期以来一直在争论架构的定义。对于某些人来说，这就像是系统的基本组织，或者是将最高级别的组件连接在一起的方式。 我对此的想法是由与拉尔夫·约翰逊（Ralph Johnson）进行的电子邮件交流形成的，后者对这一措辞提出了质疑，认为没有客观的方法来定义基础知识或高级知识，而对架构的一个更好的视角是专家开发人员达成共识的系统设计。

  架构的第二种常见定义方式是“需要在项目早期就做出设计决策”，但拉尔夫也对此表示抱怨，说这更像是你希望能够在项目的早期就做出正确的决策。
  他的结论是“架构是关于重要的东西，不管是什么。” 乍一看，这听起来很老套，但我发现它带有很丰富的内涵。 这意味着从结构的角度思考软件的的核心是确定重要的东西（即什么是架构），然后花精力保持那些架构元素处于良好状态。对于要成为架构师的开发人员来说，他们需要能够识别哪些要素很重要，以及哪些元素在被控制的情况下可能会导致严重的问题。

为什么架构很重要？

  对于软件产品的客户和用户而言，架构是一个棘手的问题-因为这不是他们能马上感知的东西。但是，糟糕的架构是促成杂乱无章的主要因素，杂乱无章是软件的要素，阻碍了开发人员理解软件的能力。包含大量附加内容的软件难以修改，导致功能实现的速度更慢，缺陷也很多。

  这种情况与我们通常的经验背道而驰。 我们习惯了“高品质”的东西看作是价格更高的东西。对于软件的某些方面（比如用户体验），这可能是正确的。但是当涉及到架构和内部质量的其他方面时，这种关系就反过来了。高的内部质量可以更快地交付新功能，因为减少了麻烦。
  虽然我们可以在短期内牺牲质量来换取更快的交货速度，但在货物堆积产生影响之前，人们低估了货物堆积导致整体交货速度较慢的速度。虽然这不是可以客观衡量的东西，但是经验丰富的开发人员认为，关注内部质量只需要几周而不是几个月就可获得回报。

应用架构

  软件开发中的重要决策会随着我们所考虑的上下文规模而变化。常见的规模是应用程序的规模，因此是“应用程序架构”。
  定义应用架构的第一个问题是对应用是什么没有明确的定义。我认为应用是一种社会结构：

• 被开发人员视为一个单元的代码体
• 业务客户将其视为一个单元的一组功能
• 那些有钱的人将其视为单一预算

  如此宽松的定义导致应用的潜在规模很多，开发团队的人数从几人到几百人不等。（您会注意到，我认为规模是涉及的人员数量，我认为这是衡量此类事情的最有用方法。）此架构与企业架构之间的主要区别在于，围绕社会构建有一个重要程度的统一目标。

应用边界

  软件开发中尚未解决的问题之一就是确定软件的边界是什么。（浏览器是不是操作系统的一部分？）面向服务体系结构的许多支持者认为应用将不复存在-因此，未来的企业软件开发将致力于将服务组装在一起。
  我不认为应用的消失和应用界限难以划分的原则一样的。本质上，应用是一种社会结构：
马丁 · 福勒
2003.9.11

微服务指南

微服务架构模式是一种将单个应用程序开发为一组小服务的方法，每个小服务都在自己的进程中运行并与轻量级机制（通常是HTTP资源API）进行通信。这些服务围绕业务功能构建，并且可以由完全自动的部署机制独立部署。这些服务可以用不同的编程语言编写，使用不同的数据存储技术，对这些服务可进行最基本的集中管理。尽管它们的优势使它们在最近几年非常流行，但它们却伴随着分销增加、一致性降低和需要成熟的经营管理的代价。
马丁·福勒

Serverless 架构

无服务器架构是结合第三方“后端即服务”（BaaS）服务和/或包含在“功能即服务”（FaaS）平台上的托管临时容器中运行的自定义代码的应用设计。通过使用这些思想以及诸如单页应用程序之类的相关思想，这样的架构消除了对传统的永远在线服务器组件的大量需求。无服务器架构可能会受益于显着降低的运营成本、复杂性和工程交货时间，但代价是增加对于供应商的依赖性和相对不成熟的支持服务的依赖。
迈克·罗伯茨
2018.5.22

微前端

好的前端开发很难。扩展前端开发，使许多团队可以同时从事大型复杂产品开发则更加困难。在本文中，我们将描述最近的一种趋势，即将前端整体拆分成许多更小、更易于管理的部分，以及这种体系结构如何提高处理前端代码的团队效率。除了讨论各种收益和成本外，我们还将介绍一些可用的实现选项，并且将深入研究一个演示该技术的完整示例应用。
卡姆·杰克逊
2019.6.19

GUI 架构

在 21 世纪中期，我一直在从事一些写作项目，这些项目本可以成书，但尚未完成。一个是关于用户界面的架构。作为这项工作的一部分，我起草了一份关于GUI架构演变的描述，比较了表单和控件的默认方法和模型-视图-控制器（MVC）模式。MVC 是软件世界中最难理解的模式之一，这是可以理解的，因为它没有很好的文档记录。因此，我在这里的写作试图更好地了解MVC的真正含义以及它如何通过模型-视图-表示器（Model-View-Presenter）和其他形式发展起来的。
2006.7.18

展现域数据屋

模块化一个信息丰富的程序的一种最常见方法是将其分为三层：展现（UI），域逻辑（即业务逻辑）和数据访问。因此，你经常会看到Web 应用程序被划分为Web 层（了解如何处理 HTTP 请求和呈现 HTML）、业务逻辑层（包含验证和计算），数据访问层（整理如何管理数据库或远程服务中的持久性数据） 。
马丁·福勒
2015.8.26

企业架构

  应用架构集中于某种形式的概念性应用边界内的体系结构，而企业架构看起来是跨大型企业的体系结构。这样的组织通常太大了，无法将其所有软件按任何一种有凝聚的方式进行分组，因此需要跨多个具有相互独立开发的代码库的团队进行协调，并需要资金和用户彼此独立运作。
  企业架构的大部分内容都是关于了解什么是值得集中协调的成本，以及协调应采取什么形式。一个极端是中央架构小组，它必须批准企业中每个软件系统的所有架构决策。这样的小组减慢了决策的速度，无法真正理解如此广泛的系统组合中的问题，从而导致决策不力。但是另一个极端是根本没有协调，这导致团队重复工作，不同系统无法进行互操作以及团队之间缺乏技能开发和交叉学习。
  像大多数具有敏捷心态的人一样，我更喜欢在分散化方面犯错，因此会更趋于混乱，而不是令人窒息的控制。但是，站在渠道的那一边仍然意味着我们必须避开险阻，并以要最小化实际成本的方式最大化本地决策。

企业架构师加入团队

企业架构组经常远离日常开发。这可能会导致他们对开发工作的了解过时，抱怨开发团队没有从整个公司的角度出发。我的同事（ThoughtWorks CTO）Rebecca 经常看到这种情况发生，她认为加入开发团队可以提高企业架构师的效率。
瑞贝卡·帕森斯（Rebecca Parsons）
2005.9

企业架构师在精益企业中的角色

当组织采取敏捷的思维方式时，企业架构不会消失，但是企业架构师的角色会发生变化。 企业架构师不再做出选择，而是帮助其他人做出正确的选择，然后传播这些信息。企业架构师仍然需要形成愿景，然后需要在团队之间建立桥梁，以构建学习社区。这将允许团队与企业架构师作为合作伙伴，在发展中探索新方法并相互学习。
凯文·希基
2015.11.30

产品超越项目

软件项目是一种流行的资助和组织软件开发的方式。他们将工作组织成临时的、只负责构建的团队，并由业务案例中预计的特定收益提供资金。产品模式使用持久的，由构思-构建-运行的团队来解决持续存在的业务问题。产品模式使团队能够快速重新定位，减少端到端的周期时间，并允许通过使用短周期迭代来验证实际收益，同时保持软件体系结构的完整性，以保持其长期有效性。
斯里拉姆·纳拉扬（Sriram Narayan）
2018.2.20

建筑师电梯-参观高层

许多大型组织都将其 IT 引擎与行政顶层公寓分隔开许多层，这也将业务和数字战略与执行它的重要工作区分开来。 架构师的主要作用是乘坐顶层公寓和机房之间的电梯，在任何需要的地方停下来支持这些数字工作：自动化软件制造、最小化前期决策并在技术发展的同时影响组织。
格雷戈尔·霍佩（Gregor Hohpe）
2017.5.24

使用 REST 进行企业集成

大多数内部 EST API 是为单个集成点构建的一次性API。在本文中，我将讨论非公共 API 所具有的约束和灵活性，以及在多个团队之间进行大规模 RESTful 集成的经验教训。
布兰登·拜尔斯（Brandon Byars）
2013.11.18