转载

软件架构指南 - martinfowler

当软件行业的人们谈论“架构”时，他们指的是软件系统内部设计最重要方面的一个模糊定义的概念。良好的架构很重要，否则将来添加新功能会变得更慢，更昂贵。

像软件世界中的许多人一样，我长期以来一直对“架构”一词持谨慎态度，因为它常常暗示了与编程的分离和不健康的浮夸。但我通过强调良好的架构是支持其自身发展的东西来解决我的问题，并且与编程密切相关。我职业生涯的大部分时间都围绕着好的架构是什么样的问题，团队如何创建它，以及如何在我们的开发组织中最好地培养建筑思维。本页概述了我对软件架构的看法，并指出了有关该站点架构的更多资料。

什么是架构？

软件世界的人们一直在争论架构的定义。对于某些人来说，它类似于系统的基本组织，或者最高级别组件连接在一起的方式。我对此的想法是通过与拉尔夫·约翰逊（ Ralph Johnson）进行电子邮件交流而形成的，他质疑这种措辞，认为没有客观的方法来定义什么是基础或高级别，更好的架构观点是 专家开发人员的共同理解拥有系统设计。

架构的第二种常见定义是，它是“需要在项目早期做出的设计决策”，但拉尔夫也抱怨这一点，并说这更像 是你希望你能早日对一个项目做出的决定。

他的结论是 “架构是重要的东西。无论那是什么“ 。乍一看，这听起来很陈旧，但我发现它带来了很多丰富。这意味着在架构上思考软件的核心是：判决什么是重要的（即什么是架构），然后花费精力来保持这些架构元素的良好状态。要让开发人员成为架构师，他们需要能够识别哪些元素是重要的，识别哪些元素在不受控制时可能导致严重问题。

为什么架构很重要？

架构对于软件产品的客户和用户来说是一个棘手的主题 - 因为它不是他们立即感知的东西。但是，糟糕的架构是软件增长的主要原因 - 软件的元素阻碍了开发人员理解软件的能力。包含大量内容的软件更难以修改，导致功能更慢，更多缺陷。

这种情况与我们通常的经历相反。我们习惯于“高品质”的东西，因为它的成本更高。对于软件的某些方面，例如用户体验，这可能是真的。但是当涉及到架构和内部质量的其他方面时，这种关系就会逆转。 高内部质量可以更快地交付新功能 ，因为可以减少阻碍。

虽然我们可以在短期内牺牲质量以便更快地交付，但是在残余物的形成产生影响之前，人们会低估这种残余物导致整体交付速度变慢的速度。虽然这不是可以客观衡量的事情，但经验丰富的开发人员认为， 对内部质量的关注会在数周而非数月内得到回报。

应用架构

软件开发中的重要决策因我们正在考虑的环境规模而异。常见的规模是应用程序的规模，因此是“应用程序架构”。

定义应用程序体系结构的第一个问题是，没有明确定义应用程序是什么。我的观点是应用是一种社会建构：

开发人员将其视为一个单元的代码体
企业客户将一组功能视为一个单元
一项倡议，那些有钱的人将其视为单一预算

如此宽松的定义会导致应用程序的许多潜在大小，从开发团队的几个人到几百人不等。（您会注意到我将大小视为涉及的人数，我认为这是衡量此类事物最有用的方式。）这种与企业架构之间的关键区别在于，存在着相当程度的统一目的社会建设。

参考：

应用边界

微服务指南

无服务器架构

Micro Frontends

GUI架构

表现领域数据分层

企业架构

虽然应用架构专注于某种形式的名义应用程序边界内的体系结构，但企业架构看起来跨大型企业的体系结，这样的组织通常太大，无法将其所有软件分组到任何类型的内聚组中，因此需要跨多个具有许多代码库的团队进行协调，这些代码库彼此隔离开发，资金和用户彼此独立运行。

许多企业架构都是关于理解什么是值得中央协调的成本，以及协调应该采取什么形式。一个极端是中央架构组，必须批准企业中每个软件系统的所有架构决策。这些群体减缓了决策制定，无法真正理解如此广泛的系统组合中的问题，从而导致决策失败。但另一个极端是根本没有协调，导致团队重复工作，不能让不同的系统互操作，以及团队之间缺乏技能开发和交叉学习。

像大多数具有敏捷思维方式的人一样，我更倾向于在分权方面犯错，因此会更接近混乱的岩石而不是窒息控制。但是，在渠道的这一方面仍然意味着我们必须避开岩石，并以最小化所涉及的实际成本的方式最大化地方决策。

参考：

企业架构师加入团队

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

产品超过项目

建筑师电梯 - 访问较高楼层

原文 https://www.jdon.com/52981

正文到此结束