软件架构指南

【注】本文节译自： 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