第 1 章 什么是架构

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

  • 模块、连接、依赖和接口;
  • 大局观;
  • 改变成本很高的事情;
  • 难以改变的事情;
  • 更加兼顾全局的设计;
  • 接口而非实现;
  • 审美(比如:艺术般的整洁代码);
  • 概念模型;
  • 满足非功能需求/质量属性;
  • 每件事都有“架构”;
  • 沟通能力(抽象、语言、词汇);
  • 计划;
  • 一定程度的严格和可靠性;
  • 蓝图;
  • 系统、子系统、交互和接口;
  • 管理;
  • 战略决策的产出;
  • 必要的约束;
  • 结构(组件和交互);
  • 技术方向;
  • 战略和愿景;
  • 结构单元;
  • 实现目标的过程;
  • 标准和准则;
  • 整个系统;
  • 工具和方法;
  • 从需求到最终产品的道路;
  • 指导原则;
  • 技术领导力;
  • 构成产品的元素之间的关系;
  • 对环境约束和限制的意识;
  • 基础;
  • 抽象的观点;
  • 把问题化整为零的过程;
  • 产品的骨架、支柱。

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

作为名词

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

作为动词

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