【注】本文节译自: Software Architecture Guide (martinfowler.com)
当软件行业的人们谈论“架构”时,他们指的是软件系统内部设计最重要方面的一个模糊定义概念。好的架构很重要,否则将来增加新功能会变得越来越慢,而且成本更高。
像软件世界中的许多人一样,我一直对“架构”一词持谨慎态度,因为它通常暗示着与编程的分离和不健康的浮夸。但是,我通过强调好的架构可以支持其自身的发展,并与编程紧密地交织在一起,来解决我的担忧。我的职业生涯大部分时间都围绕着以下问题:好的架构是什么样的,团队如何创建它,以及如何最好地在我们的开发组织中培养架构思维。该页面概述了我对软件架构的看法,并在这个网站上有关为你带来更多关于架构的材料。martinfowler.com 上有关软件体系结构的材料指南。
马丁·福勒
2019年8月1日
什么是架构?
软件界的人们长期以来一直在争论架构的定义。对于某些人来说,这就像是系统的基本组织,或者是将最高级别的组件连接在一起的方式。 我对此的想法是由与拉尔夫·约翰逊(Ralph Johnson)进行的电子邮件交流形成的,后者对这一措辞提出了质疑,认为没有客观的方法来定义基础知识或高级知识,而对架构的一个更好的视角是专家开发人员达成共识的系统设计。
架构的第二种常见定义方式是“需要在项目早期就做出设计决策”,但拉尔夫也对此表示抱怨,说这更像是你希望能够在项目的早期就做出正确的决策。
他的结论是“架构是关于重要的东西,不管是什么。” 乍一看,这听起来很老套,但我发现它带有很丰富的内涵。 这意味着从结构的角度思考软件的的核心是确定重要的东西(即什么是架构),然后花精力保持那些架构元素处于良好状态。对于要成为架构师的开发人员来说,他们需要能够识别哪些要素很重要,以及哪些元素在被控制的情况下可能会导致严重的问题。
拉尔夫的电子邮件构成了我在IEEE软件专栏的核心,该专栏讨论了软件架构的含义和架构师的角色。
为什么架构很重要?
对于软件产品的客户和用户而言,架构是一个棘手的问题-因为这不是他们能马上感知的东西。但是,糟糕的架构是促成杂乱无章的主要因素,杂乱无章是软件的要素,阻碍了开发人员理解软件的能力。包含大量附加内容的软件难以修改,导致功能实现的速度更慢,缺陷也很多。
这种情况与我们通常的经验背道而驰。 我们习惯了“高品质”的东西看作是价格更高的东西。对于软件的某些方面(比如用户体验),这可能是正确的。但是当涉及到架构和内部质量的其他方面时,这种关系就反过来了。高的内部质量可以更快地交付新功能,因为减少了麻烦。
虽然我们可以在短期内牺牲质量来换取更快的交货速度,但在货物堆积产生影响之前,人们低估了货物堆积导致整体交货速度较慢的速度。虽然这不是可以客观衡量的东西,但是经验丰富的开发人员认为,关注内部质量只需要几周而不是几个月就可获得回报。
在2015年的OSCON上,我作了简短的演讲(14分钟),内容涉及什么是架构及其重要性。
应用架构
软件开发中的重要决策会随着我们所考虑的上下文规模而变化。常见的规模是应用程序的规模,因此是“应用程序架构”。
定义应用架构的第一个问题是对应用是什么没有明确的定义。我认为应用是一种社会结构:
- 被开发人员视为一个单元的代码体
- 业务客户将其视为一个单元的一组功能
- 那些有钱的人将其视为单一预算
如此宽松的定义导致应用的潜在规模很多,开发团队的人数从几人到几百人不等。(您会注意到,我认为规模是涉及的人员数量,我认为这是衡量此类事情的最有用方法。)此架构与企业架构之间的主要区别在于,围绕社会构建有一个重要程度的统一目标。
应用边界
软件开发中尚未解决的问题之一就是确定软件的边界是什么。(浏览器是不是操作系统的一部分?)面向服务体系结构的许多支持者认为应用将不复存在-因此,未来的企业软件开发将致力于将服务组装在一起。
我不认为应用的消失和应用界限难以划分的原则一样的。本质上,应用是一种社会结构:
马丁 · 福勒
2003.9.11
微服务指南
image微服务架构模式是一种将单个应用程序开发为一组小服务的方法,每个小服务都在自己的进程中运行并与轻量级机制(通常是HTTP资源API)进行通信。这些服务围绕业务功能构建,并且可以由完全自动的部署机制独立部署。这些服务可以用不同的编程语言编写,使用不同的数据存储技术,对这些服务可进行最基本的集中管理。尽管它们的优势使它们在最近几年非常流行,但它们却伴随着分销增加、一致性降低和需要成熟的经营管理的代价。
马丁·福勒
Serverless 架构
image无服务器架构是结合第三方“后端即服务”(BaaS)服务和/或包含在“功能即服务”(FaaS)平台上的托管临时容器中运行的自定义代码的应用设计。通过使用这些思想以及诸如单页应用程序之类的相关思想,这样的架构消除了对传统的永远在线服务器组件的大量需求。无服务器架构可能会受益于显着降低的运营成本、复杂性和工程交货时间,但代价是增加对于供应商的依赖性和相对不成熟的支持服务的依赖。
迈克·罗伯茨
2018.5.22
微前端
image好的前端开发很难。扩展前端开发,使许多团队可以同时从事大型复杂产品开发则更加困难。在本文中,我们将描述最近的一种趋势,即将前端整体拆分成许多更小、更易于管理的部分,以及这种体系结构如何提高处理前端代码的团队效率。除了讨论各种收益和成本外,我们还将介绍一些可用的实现选项,并且将深入研究一个演示该技术的完整示例应用。
卡姆·杰克逊
2019.6.19
GUI 架构
在 21 世纪中期,我一直在从事一些写作项目,这些项目本可以成书,但尚未完成。一个是关于用户界面的架构。作为这项工作的一部分,我起草了一份关于GUI架构演变的描述,比较了表单和控件的默认方法和模型-视图-控制器(MVC)模式。MVC 是软件世界中最难理解的模式之一,这是可以理解的,因为它没有很好的文档记录。因此,我在这里的写作试图更好地了解MVC的真正含义以及它如何通过模型-视图-表示器(Model-View-Presenter)和其他形式发展起来的。
2006.7.18
展现域数据屋
image模块化一个信息丰富的程序的一种最常见方法是将其分为三层:展现(UI),域逻辑(即业务逻辑)和数据访问。因此,你经常会看到Web 应用程序被划分为Web 层(了解如何处理 HTTP 请求和呈现 HTML)、业务逻辑层(包含验证和计算),数据访问层(整理如何管理数据库或远程服务中的持久性数据) 。
马丁·福勒
2015.8.26
企业架构
应用架构集中于某种形式的概念性应用边界内的体系结构,而企业架构看起来是跨大型企业的体系结构。这样的组织通常太大了,无法将其所有软件按任何一种有凝聚的方式进行分组,因此需要跨多个具有相互独立开发的代码库的团队进行协调,并需要资金和用户彼此独立运作。
企业架构的大部分内容都是关于了解什么是值得集中协调的成本,以及协调应采取什么形式。一个极端是中央架构小组,它必须批准企业中每个软件系统的所有架构决策。这样的小组减慢了决策的速度,无法真正理解如此广泛的系统组合中的问题,从而导致决策不力。但是另一个极端是根本没有协调,这导致团队重复工作,不同系统无法进行互操作以及团队之间缺乏技能开发和交叉学习。
像大多数具有敏捷心态的人一样,我更喜欢在分散化方面犯错,因此会更趋于混乱,而不是令人窒息的控制。但是,站在渠道的那一边仍然意味着我们必须避开险阻,并以要最小化实际成本的方式最大化本地决策。
企业架构师加入团队
image企业架构组经常远离日常开发。这可能会导致他们对开发工作的了解过时,抱怨开发团队没有从整个公司的角度出发。我的同事(ThoughtWorks CTO)Rebecca 经常看到这种情况发生,她认为加入开发团队可以提高企业架构师的效率。
瑞贝卡·帕森斯(Rebecca Parsons)
2005.9
企业架构师在精益企业中的角色
image当组织采取敏捷的思维方式时,企业架构不会消失,但是企业架构师的角色会发生变化。 企业架构师不再做出选择,而是帮助其他人做出正确的选择,然后传播这些信息。企业架构师仍然需要形成愿景,然后需要在团队之间建立桥梁,以构建学习社区。这将允许团队与企业架构师作为合作伙伴,在发展中探索新方法并相互学习。
凯文·希基
2015.11.30
产品超越项目
软件项目是一种流行的资助和组织软件开发的方式。他们将工作组织成临时的、只负责构建的团队,并由业务案例中预计的特定收益提供资金。产品模式使用持久的,由构思-构建-运行的团队来解决持续存在的业务问题。产品模式使团队能够快速重新定位,减少端到端的周期时间,并允许通过使用短周期迭代来验证实际收益,同时保持软件体系结构的完整性,以保持其长期有效性。
斯里拉姆·纳拉扬(Sriram Narayan)
2018.2.20
建筑师电梯-参观高层
image许多大型组织都将其 IT 引擎与行政顶层公寓分隔开许多层,这也将业务和数字战略与执行它的重要工作区分开来。 架构师的主要作用是乘坐顶层公寓和机房之间的电梯,在任何需要的地方停下来支持这些数字工作:自动化软件制造、最小化前期决策并在技术发展的同时影响组织。
格雷戈尔·霍佩(Gregor Hohpe)
2017.5.24
使用 REST 进行企业集成
image大多数内部 EST API 是为单个集成点构建的一次性API。在本文中,我将讨论非公共 API 所具有的约束和灵活性,以及在多个团队之间进行大规模 RESTful 集成的经验教训。
布兰登·拜尔斯(Brandon Byars)
2013.11.18
网友评论