写在前面
软件行业里，人们谈起“架构”时，指的是对软件系统内部设计最重要的方面进行模糊定义的概念。良好的架构很重要，否则将来新增功能会变得越来越慢，成本也会变高
但“架构”一词应谨慎对待，因为通常意味着与编程的分离，甚至浮华夸大。而我们真正关注的是能够支持其自身的演变，并且与编程密不可分的好的架构，那么：
好的架构是什么样的？
团队怎样才能创造出好的架构？
如何在我们的开发组织中培养架构思维？
一.什么是架构？
架构的定义，是软件行业一直以来争论不休的一个话题。有人认为架构是系统的基本组织方式，也有人认为是把最高层组件连接在一起的方式。可是，“基础”、“高层次”的客观定义又是什么呢？所以，更好的看法是专家开发人员对系统设计所形成的共识
P.S.还有一种常见的定义，认为架构是需要在项目早期做出的设计决策，同样不够准确，因为更像是希望能够在项目中尽早做出的决定
Ralph Johnson 认为，架构是那些重要的东西，无论它具体是什么：
Architecture is about the important stuff. Whatever that is.
听起来比较老套，但有些道理，因为从架构角度考虑的核心就是要确定什么才是重要的东西（即，什么是架构），然后投入精心让这些架构元素保持良好状态。对于要成为架构师的开发者来说，要能识别出那些重要的元素，以及那些如果不加以控制就会造成严重后果的元素
P.S.关于架构定义的更多信息，见Who Needs an Architect?
二.为什么架构如此重要？
对于软件产品的客户和用户而言，架构是个棘手的问题，因为这不是他们所能立即感知到的。但糟糕的架构却是促成杂乱无章（cruft）的主要因素，这些东西会妨碍开发者理解软件。包含大量杂乱的东西的软件难以修改，从而导致特性迭代速度变慢、缺陷变多：
更严重的是，由于这些杂乱的东西遍布整个代码库，会拖慢每一次功能迭代
习惯经验告诉我们，通常高质量的东西成本也更高，对于软件的某些方面（比如用户体验），确实是这样，但在涉及架构和内部质量的其它方面时，这种关系恰恰相反：高内部质量能加快新功能的交付速度，因为来自杂乱的东西的阻碍减少了
诚然，短期内我们可以为了更快的交付而牺牲质量，但在杂乱的东西堆积尚未产生影响之前，人们低估了它拖慢整体交付的迅速程度。虽然无法客观衡量，但有经验的开发者知道，对内部质量的关注在几周内就能得到回报（而不是几个月）
高内部质量的软件前期交付慢，但后期交付速度要快得多
P.S.关于软件内部质量与成本的更多信息，见Is High Quality Software Worth the Cost?
三.应用程序架构
软件开发中的重要决策因我们所考虑的上下文范围而异，常见的范围是应用程序，即应用程序架构
定义软件架构的第一个问题是没有明确定义什么是应用程序，本质上，应用程序可以理解为一种社会结构：
在开发人员看来（应用程序）是一堆代码
在业务客户看来是一组功能
在投资人看来是一个预算计划
这种宽松的定义导致存在规模大大小小的应用，开发团队从几个人到几百个人不等（把规模看做所涉及的人数是最有用的衡量方式），与企业架构的主要区别在于，围绕社会结构存在着很大程度的统一目标
应用程序的边界
软件开发中尚未解决的问题之一是如何确定软件的边界是什么，例如，浏览器是不是操作系统的一部分？
本质上，应用程序是社会结构，我们能以几百种不同的方式描绘软件边界（开发人员、业务客户、投资人等视角），在许多方面，这些界限是由人际关系和政治所划定的，而不是基于技术及功能上的考虑
P.S.更多详细信息，见ApplicationBoundary
微服务模式
微服务架构模式是一种把单个应用程序分解成一套小型服务来开发的方法，每个小服务运行在自己的进程，并通过轻量级的机制通信（通常是 HTTP 面向资源的 API）。这些服务围绕业务功能建立，由完全自动化的部署机制独立部署，可以用不同语言来编写，也可以使用不同的数据存储技术，而只需要极少的集中管理
这些优势让微服务模式在过去几年变得非常流行，但分布式成本增加，一致性减弱，以及操作管理上的成熟度要求等代价也随之而来
P.S.更多详细信息，见微服务架构（Microservices）
Serverless 架构
Serverless 架构是一种包含第三方 BaaS（Backend as a Service）服务，以及运行在 FaaS（Functions as a Service）平台上托管的临时容器中的自定义代码的应用程序设计。通过运用这些思想和单页面应用等相关思想，这种架构消除了对传统始终运行的服务端组件的大部分需求
Serverless 架构有助于大幅降低运营成本、复杂度和工程交付周期，但代价是增加了对供应商的依赖以及相对不成熟的支持服务
P.S.更多详细信息，见伯克利研究员们眼中的 Serverless Computing、Serverless Architectures
微前端模式
前端开发要做好很难，而扩展前端开发，让多个团队能够同时处理大而复杂的产品更难
微前端模式是近年来出现的一种把前端整体拆分成许多易于管理的小块，以提升前端团队效率的流行趋势
P.S.更多详细信息，见Micro Frontends
GUI 架构
从最初的表单加控件，到后来的 MVC、MVP 等模式，UI 架构也在不断演进
P.S.更多详细信息，见GUI Architectures
表现-领域逻辑-数据分层
对于信息丰富的程序，最常见一种模块化方法是把它分成 3 层：
表现层（UI）
领域逻辑层（或者叫业务逻辑层）
数据访问层
所以经常看到 Web 应用分成负责处理 HTTP 请求和渲染 HTML 的 Web 层、包含校验与计算的业务逻辑层，以及用数据库或远程服务管理持久化数据的数据访问层：
分层最大的好处在于缩窄关注范围，让我们能单独考虑这 3 部分。由于确立了模块边界，让换用不同的实现的影响范围变得相对较小，也更容易独立测试
P.S.更多详细信息，见Presentation Domain Data Layering
四.企业架构
应用程序架构专注于某种形式的概念性应用程序边界内的架构，而企业架构则是着眼于整个大型企业的架构。企业组织通常太庞大，而无法将其所有软件按内聚的方式进行划分，因此需要对各自拥有许多代码库的团队进行协调，这些团队彼此之间独立开发，资金和用户也独立运作
企业架构的许多内容都是关于什么样的中心化协调才是值当的，以及协调应采取的形式。一种极端情况是中心化架构划分，必须批准企业下每个软件系统的所有架构决策，这种划分拖慢了决策速度，而且无法真正理解广泛的系统组合中的各种问题，从而导致决策不力。另一种极端是完全没有协调，导致团队重复工作，不同系统之间无法进行互操作，团队间也缺乏技能培养和交叉学习
对此，与其进行束缚性的控制，不如权力下放，同时尽可能地加强局部决策，最大限度地减少所涉及的实际成本
让企业架构师加入开发团队
企业架构组通常与日常开发分开，这会导致他们对开发工作的认知过时，而且开发团队也没有从全公司的广泛视角来看。因此，企业架构师或许可以通过加入开发团队来提高效率
P.S.更多详细信息，见Enterprise Architects Join the Team
精益企业中的企业架构师角色变化
企业采用敏捷思维时，企业架构不会消失，但企业架构师的角色会发生变化：
企业架构师不再做出选择，而是帮助他人做正确的决策，然后传播这些信息
企业架构师仍然需要形成愿景，但随后要在团队之间架起桥梁，建立学习社区
企业架构师要与团队建立合作伙伴关系，在成长中探索新方法并相互学习
P.S.更多详细信息，见The Role of an Enterprise Architect in a Lean Enterprise
产品模式胜过项目模式
项目模式，是按软件项目进行资金投入和组织软件开发的一种流行方式，把工作组织成临时的，只负责实现的团队，并由业务场景中预计的特定收益提供资金
而产品模式改用持久的，负责构思、实现及运行的团队，以解决持续存在的业务问题。产品模式让团队能够快速调整方向，减少端到端的周期时间，并通过短周期迭代来验证实际收益，同时维持软件架构的完整性来保证其长期有效
P.S.更多详细信息，见Products Over Projects
架构师的职责
许多大型组织的 IT 部门与拥有决策权的高层之间都分隔着许多层楼，这也把业务和数字化战略与实施战略的重要工作分开了
所以，架构师的主要职责是乘坐顶层到机房的电梯，在任何需要支持其数字化工作的地方停下来：自动化软件生产，尽可能减少前期决策，并在技术演进的同时影响组织
P.S.更多详细信息，见The Architect Elevator — Visiting the upper floors
