第1章 什么是架构

在不同的人眼里“架构”一词的意思大相径庭，互联网上对架构的定义也多如牛毛。过去几年里我问过上百人同一个问题，在他们看来“架构”意味着什么。得到的答案概括如下（排名不分先后）：

❑ 模块、连接、依赖和接口；

❑ 大局观；

❑ 改变成本很高的事情；

❑ 难以改变的事情；

❑ 更加兼顾全局的设计；

❑ 接口而非实现；

❑ 审美（比如：艺术般的整洁代码）；

❑ 概念模型；

❑ 满足非功能需求/质量属性；

❑ 每件事都有“架构”；

❑ 沟通能力（抽象、语言、词汇）；

❑ 计划；

❑ 一定程度的严格和可靠性；

❑ 蓝图；

❑ 系统、子系统、交互和接口；

❑ 管理；

❑ 战略决策的产出；

❑ 必要的约束；

❑ 结构（组件和交互）；

❑ 技术方向；

❑ 战略和愿景；

❑ 结构单元；

❑ 实现目标的过程；

❑ 标准和准则；

❑ 整个系统；

❑ 工具和方法；

❑ 从需求到最终产品的道路；

❑ 指导原则；

❑ 技术领导力；

❑ 构成产品的元素之间的关系；

❑ 对环境约束和限制的意识；

❑ 基础；

❑ 抽象的观点；

❑ 把问题化整为零的过程；

❑ 产品的骨架、支柱。

难怪找不到一个合适的定义！好在还可以分为名词和动词两大类。无论我们谈论的是建造一个物理建筑或一个软件系统，都适用。

作为名词

架构作为名词来解释时，概括起来都与结构有关：将产品分解为一系列组件、模块和交互。这需要考虑整个产品，包括处理（建筑物的）供电、供水、空调，或处理（软件的）安全、配置、错误处理等横切关注点的基础设施服务。

作为动词

架构作为动词来解释时，包括了理解你需要构建什么、设定愿景以便于进行构建和做出恰当的设计决策。所有这些都要以需求为基础，因为需求驱动架构。关键在于，架构是关于交流愿景以及引入技术领导力的，这样参与构建产品的每个人都能理解这个愿景，并为产品的成功做出积极贡献。