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