架构思维方法论（AT）：世界 500 强最爱用的“多视角八股文”架构思维方法论（AT）：世界 500 强最爱用的“多视角

架构思维方法论（AT）：世界 500 强最爱用的“多视角八股文”

AT = Architecture Thinking。
它不是一门新技术，而是一套“如何系统性地思考和表达架构”的方法论。

相对前面两章的 ABSD（需求驱动）和 DSSA（领域驱动），AT 更像是：

一套“通用架构思维框架”；
专门帮你解决：
- 怎么整理需求？
- 怎么用多种视角画出清晰的架构？
- 怎么写出“世界 500 强审阅也看得懂”的架构文档？

一、AT 的两个核心：需求驱动 + 多视角

1. 依然是“需求驱动”，但结构更清晰

AT 也坚持“所有架构都从需求出发”，并把需求分成三大类：

功能性需求（Functional Requirements）
- 例如电商网站中：
  - 浏览商品、下单、支付、发货、售后等；
- 在 AT 里通常用：
  - 用例图 + 用例描述表来归纳整理。
非功能性 / 质量需求（Quality Attributes）
- 高可用（Availability）、扩展性（Scalability）、性能（Performance）、
  稳定性 / 可靠性（Reliability）、安全性（Security）、可维护性（Maintainability）、
  易用性（Usability）、可测试性（Testability）……
- 它们决定了系统能不能“跑大、跑稳、跑久”。
限制 / 约束需求（Constraints）
- 企业级约束：预算、投产时间、团队能力、统一技术栈等；
- 行业 / 法规约束：比如不允许销售军用品，数据不能出境等。

AT 做的第一件事，就是把这些内容“对号入座”，形成比较标准化的需求输入文档，而不是零散口头需求。

2. 多视角：用“架构立方体”看系统

AT 最有特点的是一个“架构立方体”的思维模型，三个维度：

Z 轴：业务 / 应用视角（What）
- 看“应用 / 系统”本身做什么：购买系统、卖家系统、支付系统、客服系统……
- 是做“功能划分”和“边界识别”的视角。
X 轴：逻辑技术视角（Logical Technology）
- 不看具体产品名，而是看“技术职责”：
  - 消息队列承担异步通讯、削峰填谷；
  - 网关承担路由、限流、鉴权；
  - 缓存承担热点数据加速等。
Y 轴：物理技术视角（Physical Technology）
- 把逻辑技术映射成具体选型：
  - MQ 用 Kafka 还是 RabbitMQ？
  - 缓存用 Redis 还是 Memcached？
  - 部署在 K8s 还是虚机？单 AZ 还是多 AZ？

此外还有两组“外视角”：

功能视角 vs 运行视角
- 功能视角：系统要实现哪些能力（对用户 / 对内部应用）；
- 运行视角：在目标 QPS / TPS、节点数、故障场景下系统怎么表现。

你可以理解为：
业务 / 应用视角 决定“画哪些框”；
逻辑技术视角 决定“框之间怎么连”；
物理技术视角 决定“这些框到底跑在哪儿，用什么堆出来”；
运行视角 把目标容量和可靠性“压”到这个立方体上做验证。

二、AT 在大公司里的落地模样：需求 → 多视图 → 文档体系

很多世界 500 强的“企业架构文档”，其实都在做三件事：

需求文档（Requirements）
- 功能需求：用例列表 + 描述；
- 质量需求：性能 / 可用 / 操作 / 管理 / 弹性 / 安全 / 可维护 / 可测试 / 易用……
- 约束需求：预算、法规、技术栈限制等。
多视角架构文档（Architecture Views）
通常会按某种剪裁方式，从立方体抽出几个主视图：
- 业务视图：
  - 描述业务流程、业务能力地图、部门 / 角色与系统的关系；
- 应用视图：
  - 描述系统 / 应用之间的调用关系、接口协作；
- 数据视图：
  - 数据域划分、主数据 / 交易数据 / 分析数据、流向链路；
- 技术视图：
  - 中间件、基础设施、部署拓扑（逻辑 + 物理）、技术标准和规范。
演进与更新机制
- 不是画完一版就束之高阁；
- 而是：每有较大变更（业务 / 技术），就迭代相应视图；
- 有的企业甚至做到“每月一版架构图”，输入来自：
  - 代码与基础设施的真实变动；
  - 新上线系统 / 新退役系统；
  - 质量与容量测试数据。

换句话说，AT 在大公司中的价值是：
让所有架构设计有统一的输入格式、统一的视角结构、统一的输出文档。

三、AT 对你个人有什么用？三种典型场景

1. 认证考试 / 软考：把答案写成“有方法论”的样子

不论是 Open Group 的架构认证还是国内软考，常见题型包括：

描述一个系统的整体架构；
解释如何满足某些非功能性需求；
说明如何处理某类变更或扩展。

如果你能用 AT 的语言来写：

先简述需求三类；
再按业务 / 应用 / 数据 / 技术视图简要展开；
提及用例图、组件模型、运行模型等术语；

阅卷人一般会很快判断：
你至少在“架构表达”上是受过系统训练的。

2. 面试 / 晋升：画图 & 讲解更有“体系感”

很多架构师面试会要求：

在白板上画一个你负责的系统架构；
说明你是怎么设计的、怎么考虑性能 / 可用 / 安全的。

如果你脑子里有 AT 的立方体，可以这样组织：

先画 业务 / 应用视图：
- 哪些系统 / 服务，负责什么业务功能？
再讲 逻辑技术视图：
- 这些服务通过什么技术模式协作（MQ、API、缓存、网关）？
再落到 物理视图：
- 部署在什么环境，如何实现容灾、扩缩容？
最后补上 运行视角：
- 目标 QPS/TPS、容量规划、压测与监控方案。

相比“只画一张含糊的框图”，AT 会让你的讲解显得有条理很多。

3. 试用期 / 新项目：快速设计一份“够用”的架构草案

很多人升到架构岗位（或试用期被要求带项目）时，会遇到：

“我代码写得还行，但让我从 0 设计一套系统，有点慌。”

AT 在这里给你的是一个起手式：

先用需求三分类，把“要做什么”写清楚；
再用几个主视图（业务 / 应用 / 技术）勾勒出初稿；
每 1～2 天迭代一次，把细节填实。

这比“闷头瞎画”要稳得多，也更容易让其他人理解和评审。

四、AT 在面试题里的典型用法（两道题示例）

原文最后给了两道很典型的 AT 面试题，你可以直接套用。

题目 1：你在架构设计中通常采用什么方式来描述软件架构？

可答（思路示例）：

我一般会用 多视图 的方式描述架构：
- 业务 / 应用视图：描述系统职责和相互调用关系；
- 技术视图（逻辑 + 物理）：描述中间件、运行时平台、部署拓扑；
- 运行视图：结合容量和可用性要求，说明扩缩容、容灾方案。
每个视图都源自相同的一套需求输入（功能 + 质量 + 约束），
这样不同干系人可以从自己最关心的角度理解同一个架构。

如果能顺带画一小张示意图，会更加分。

题目 2：你在架构设计中通常采用什么方法来描述需求？

可答（思路示例）：

我会优先把需求分成三类：
- 功能需求：用例图 + 用例说明；
- 质量需求：整理成质量属性矩阵（性能 / 可用 / 安全等）；
- 约束需求：预算、法规、技术栈限定等。
在此基础上，用这些需求去驱动：
- 组件模型的划分（哪些功能归哪些组件 / 服务负责）；
- 运行模型的设计（高峰流量、故障场景、弹性伸缩策略）。

这类回答能清楚地传达一个信号：
你不是“凭感觉”做架构，而是在用一种稳定的方法重复地做架构。

小结：AT 带给你的，不是“新套路”，而是一种“统一语言”

学完 AT，你可以多做三件事：

写文档 / 画图时，有意识地使用多视图结构：
- 不再用一张“大杂烩架构图”解决所有问题。
评审他人方案时，用立方体视角检查缺口：
- 只讲业务？缺技术细节；
- 只讲技术栈？缺业务关联；
- 只讲功能？质量与运行视角没覆盖。
在项目沉淀时，把“图 + 文 + 决策理由”整理成可反复复用的模板：
- 你自己的“小公司版 AT 方法论”，慢慢就出来了。

当你能持续用这种方式表达和思考架构时，不管是在团队内，还是在更大的组织里，你都会更容易被当作“真正的架构师”来看待，而不是“只是高级工程师”。