软件架构指南（2019）

软件架构指南 当软件行业的人们谈论“架构”时，他们指的是软件系统内部设计的最重要方面的一个模糊定义的概念。一个好的架构很重要，否则将来添加新功能会变得更慢、更昂贵。和软件界的许多人一样，我长期以来一直对“架构”这个术语持谨慎态度，因为它经常暗示与编程的分离和不健康的浮夸。但我通过强调优秀的架构能够支持其自身的发展，并且与编程紧密地交织在一起来解决我的担忧。我职业生涯的大部分时间都围绕着这样的问题：好的架构是什么样子，团队如何创建它，以及如何最好地在我们的开发组织中培养架构思维。本页概述了我对软件架构的看法，并为您提供了本网站上有关架构的更多材料。 martinfowler.com 上有关软件架构的材料指南。马丁·福勒 2019 年 8 月 1 日 什么是建筑？软件界的人们长期以来一直在争论架构的定义。对于某些人来说，它类似于系统的基本组织，或者最高级别组件连接在一起的方式。我对此的想法是通过与 Ralph Johnson 的电子邮件交流形成的，他对这种措辞提出了质疑，认为没有客观的方法来定义什么是基本的或高级的，并且更好的架构视图是专家开发人员对系统设计的共同理解。 Ralph Johnson 在 QCon 上发言 架构的第二种常见定义风格是“需要在项目早期做出的设计决策”，但 Ralph 也抱怨了这一点，他说这更像是您希望在项目早期就做出的决策。他的结论是“建筑是关于重要的东西。无论那是什么”。乍一看，这听起来很老套，但我发现它内涵丰富。这意味着从架构角度思考软件的核心是决定什么是重要的（即什么是架构），然后花费精力保持这些架构元素处于良好状态。对于成为架构师的开发人员来说，他们需要能够认识到哪些元素是重要的，认识到哪些元素如果不加以控制可能会导致严重的问题。 Ralph 的电子邮件构成了我的 IEEE 软件专栏的核心，其中讨论了软件架构的含义和架构师的角色。为什么建筑很重要？对于软件产品的客户和用户来说，架构是一个棘手的主题 - 因为他们不会立即感知到它。但糟糕的架构是导致缺陷增长的主要原因——软件中的一些元素阻碍了开发人员理解软件的能力。包含大量繁琐内容的软件更难修改，从而导致功能实现速度更慢且缺陷更多。这种情况与我们通常的经验相反。我们习惯于将“高质量”的东西视为成本更高的东西。对于软件的某些方面，例如用户体验，这可能是正确的。但当涉及到架构和内部质量的其他方面时，这种关系就相反了。高内部质量可以更快地交付新功能，因为阻碍的障碍更少。虽然我们确实可以在短期内牺牲质量来加快交付速度，但在垃圾堆积产生影响之前，人们低估了垃圾导致整体交付速度变慢的速度。虽然这不是可以客观衡量的事情，但经验丰富的开发人员认为，对内部质量的关注会在几周而不是几个月内得到回报。了解更多… 在 2015 年的 OSCON 上，我就什么是架构以及它为何重要做了简短的演讲（​​14 分钟）。应用程序架构 软件开发中的重要决策随着我们考虑的环境规模的不同而变化。常见的规模是应用程序的规模，因此称为“应用程序架构”。定义应用程序架构的第一个问题是应用程序是什么没有明确的定义。我的观点是，应用程序是一种社会结构： 被开发人员视为单个单元的代码体 业务客户将其视为单个单元的一组功能 有钱人将其视为单个预算的计划 这种松散的定义导致应用程序有许多潜在的规模，从开发团队中的几个人到几百人不等。 （您会注意到，我将规模视为所涉及的人员数量，我认为这是衡量此类事物的最有用方法。）这与企业架构之间的主要区别在于，围绕社会建设存在很大程度的统一目标。应用边界尚未确定之一