架构设计00--【翻译】软件架构指南
本指南是[martinfowler.com]上关于软件架构的材料指南。原文地址为：https://martinfowler.com/architecture/。
当软件行业的人们谈论“架构”时，他们指的是一个模糊定义的概念，即软件系统内部设计的最重要方面。一个好的架构是很重要的，否则在将来添加新功能会变得更慢、更昂贵。
和软件界的许多人一样，我一直对“架构”这个词保持警惕，因为它常常暗示着与编程的分离和一种不健康的浮夸。但我通过强调良好的架构是支持其自身发展的，并且与编程紧密结合的东西来解决这个问题。我的大部分职业生涯都围绕着什么样的架构是好架构的问题，并团队如何创建它，以及如何以最好的形式培养我们的组织中的架构思维。本页概述了我对软件架构的看法，并为您指出了有关本网站架构的更多资料。
什么是架构？
软件界的人们一直在争论架构的定义。对某些人来说，这就像是一个系统的基本组织，或者是最高级别的组件连接在一起的方式。我的想法是通过与拉尔夫·约翰逊（Ralph Johnson）的邮件交流形成的，他质疑这一措辞，认为没有客观的方法来定义什么是基本的，或者是高层的？好的架构是专家对系统设计的共同理解。
拉尔夫·约翰逊
第二种常见的架构定义风格是，它是“需要在项目早期做出的设计决策”，但拉尔夫也对此表示不满，他说，这更像是你希望能够在项目早期做出正确的决策。
他的结论是“架构是最重要的东西。不管那是什么”。乍一看，这听起来很老套，但我发现它有很多丰富的内容。这意味着从架构层面思考决定软件的核心什么（即什么是架构），然后花费精力保持这些架构元素处于良好的状态。为了让开发人员成为架构师，他们需要能够认识到哪些元素是重要的，认识到如果不加以控制，哪些元素可能导致严重的问题。
什么是架构问题？
对于软件产品的客户和用户来说，架构是一个棘手的话题，因为它不是他们能马上察觉到的东西。但是一个糟糕的架构是导致软件粗糙元素增长的主要原因，这些元素阻碍了开发人员理解软件。包含软件粗糙元素的系统是很难修改，并导致特性交付速度更慢，缺陷也更多。
这种情况与我们通常的经验相反。我们习惯了“高质量”的东西，认为它更贵。对于软件的某些方面，高质量符合这个标准，比如用户体验。但当涉及到架构和其他内部质量方面时，这种关系是相反的。高的内部质量导致新功能的更快交付，因为没有太多的障碍。
诚然，我们可以在短期内为更快的交付速度牺牲质量，但在粗糙元素的建立产生影响之前，人们低估了粗糙元素导致整体交付速度放缓的速度。虽然这不能客观地衡量，但有经验的开发人员认为，对内部质量的关注在几周内而不是几个月内就见效了。
应用架构
软件开发中的重要决策随着我们所考虑的上下文的规模而变化。但有一个共同的尺度是应用程序的尺度，因此是“应用程序架构”。
定义应用程序架构的第一个问题是没有明确定义应用程序是什么。我认为应用程序是一种社会结构：
- 被开发人员视为单个单元的代码体
- 业务客户视为单个单元的一组功能
- 那些有钱的人把这看作是一个单一的预算
这样一个松散的定义会导致应用程序有许多潜在的大小，从开发团队中的几个人到几百人不等。（你会注意到，我将规模视为所涉及的人员数量，我认为这是衡量这类事情的最有用的方法。）这与企业架构的关键区别在于，在社会建设方面存在着很大程度的统一目标。
应用程序边界
软件开发中一个尚未决定的问题是决定一个软件的边界是什么。（浏览器是否是操作系统的一部分？）许多面向服务架构的支持者认为应用程序正在消失，因此未来的企业软件开发将是由服务组装在一起形成的。
我不认为应用程序会因为同样的原因而消失，为什么应用程序边界如此难以划定。基本上应用是社会结构：
By Martin Fowler 2003/09/11
微服务指南
微服务架构模式是一种将单个应用程序开发为一组小型服务的方法，每个服务都在其自己的进程中运行，并与轻量级机制（通常是http资源api）通信。这些服务是围绕业务能力构建的，可以通过完全自动化的部署机制进行独立部署。对这些服务的集中管理是最低限度的，这些服务可以用不同的编程语言编写，并使用不同的数据存储技术。虽然它们的优势使它们在过去几年中非常流行，但它们带来的代价是增加分布计算、削弱一致性和要求运维成熟。
By Martin Fowler
无服务器（Serverless）架构
无服务器架构是结合第三方“后端即服务”（baas）服务和/或包括在“功能即服务”（faas）平台上的托管、临时容器中运行的自定义代码的应用程序设计。通过使用这些思想和相关的思想（如单页面应用程序），这样的体系结构消除了对传统的始终在服务器上的组件的大量需求。无服务器架构可以从显著降低的运营成本、复杂性和工程交付周期中获益，但代价是对供应商依赖性的增加和相对不成熟的支持服务。
By Mike Roberts 2018/05/22
微型前端
开发一个好前端非常困难。使许多团队能够同时处理大型复杂的产品更是难上加难。在这篇文章中，我们将描述一个最近的趋势，即将前端整体分解成许多更小、更易于管理的部分，以及这种架构如何提高前端代码开发团队的效率和效率。除了讨论各种好处和成本外，我们还将介绍一些可用的实现选项，并深入讨论演示该技术的完整示例应用程序。
BY Cam Jackson 2019/06/19
GUI架构
在2000年代中期我正在从事一些写作项目，这些项目本可以变成书但还没有成功。一个是关于用户界面的体系结构。作为这项工作的一部分，我起草了一份关于gui架构如何发展的描述，将表单和控件的默认方法和模型-视图-控制器（model-view-controller，mvc）模式进行了比较。mvc是软件世界中最难理解的模式之一，可以理解，因为它没有很好的文档记录。因此，我在这里的写作试图更好地描述mvc的真正含义，以及它是如何通过model-view-presenter和其他形式演变的。
Presentation Domain Data Layering
模块化一个信息丰富的程序最常用的方法之一是将它分为三个广泛的层：表示（ui）、域逻辑（aka business logic）和数据访问。因此，您经常会看到web应用程序被划分为了解如何处理http请求和呈现html的web层、包含验证和计算的业务逻辑层以及排序如何管理数据库或远程服务中的持久数据的数据访问层。
BY Martin Fowler 2015/08/26
企业架构
当应用程序架构集中于某种形式的概念应用程序边界内的架构时，企业架构看起来是跨大型企业的架构。这样一个组织通常规模太大，无法将其所有软件分组为任何形式的内聚分组，因此需要跨具有许多代码库的团队进行协调，这些代码库是在相互隔离的情况下开发的，资金和用户是相互独立的。
企业架构的大部分内容都是关于理解什么值得进行集中协调，以及这种协调应该采取什么形式。一个极端是一个中心架构组，它必须批准企业中每个软件系统的所有架构决策。这样的群体会减慢决策速度，无法真正理解如此广泛的系统组合中的问题，从而导致决策失误。但另一个极端是完全没有协调，导致团队重复努力，不同系统无法相互操作，团队之间缺乏技能开发和交叉学习。
像大多数思维敏捷的人一样，我更喜欢在分权方面犯错误，所以我更愿意接近混乱的岩石，而不是令人窒息的控制。但是，站在渠道的那一边仍然意味着我们必须避免触礁，并以一种能够最大限度地降低实际成本的方式来实现本地决策的最大化。
企业架构师加入团队
企业架构组经常与日常开发分离。这可能会导致他们对开发工作的认识过时，开发团队没有从公司的广泛角度来看待问题。我的同事（thoughtworks cto）rebecca经常看到这种情况，她认为通过加入开发团队，企业架构师可以更加有效。
企业架构师在精益企业中的作用
当一个组织采取敏捷的思维方式时，企业架构并没有消失，但是企业架构师的角色发生了变化。企业架构师不再做出选择，而是帮助其他人做出正确的选择，然后传播这些信息。企业架构师仍然需要形成一个愿景，但随后需要在团队之间建立桥梁来构建学习社区。这将使团队能够探索新的方法并相互学习，而企业架构师则是这种增长的合作伙伴。
架构师电梯-参观上层
许多大型组织都看到他们的it引擎被许多层楼与高层管理层隔开，高层管理层也将业务和数字战略与执行it的重要工作分开。架构师的主要职责是在顶楼和机舱之间乘坐电梯，在需要支持这些数字化工作的地方停车：自动化软件制造，最小化前期决策，并在技术发展的同时影响组织。
产品多于项目
软件项目是一种流行的资助和组织软件开发的方式。他们将工作组织成临时的、只建立团队的，并通过在业务案例中预测的特定收益来提供资金。相反，产品模式使用持久的、理想的构建-运行团队来处理持久的业务问题。产品模式允许团队快速调整方向，减少端到端的周期时间，并允许通过使用短周期迭代验证实际的好处，同时保持软件的体系结构完整性，以保持其长期有效性。
用REST进行企业集成
大多数内部REST API是专门为单个集成点构建的一次性api。在本文中，我将讨论使用非公开api的限制和灵活性，以及在多个团队中进行大规模restful集成的经验教训。
原文中附带的其他链接资源：
Who Needs an Architect?
Is High Quality Software Worth the Cost?
At OSCON in 2015 I gave a brief talk (14 min) on what architecture is and why it matters.
