T3 Stack实战：用TypeScript全栈链路重构内部报表工具
2026/10/14 7:37:11
简介：TOGAF 9.1 中文电子版面向企业架构师、IT 规划人员及备考 TOGAF 认证的学习者，用于系统掌握这一由 The Open Group 发布的架构框架。资源围绕企业架构的认可、构建、使用与维护展开，涵盖核心概念、架构定义、ENTERPRISE 概念、架构模块功能描述与要求、架构原则等知识点，并配有中文知识点总结，便于对照理解迭代流程模型与可复用架构资产。压缩包内共 1 个 PDF 文件，整体约 50.32MB，内容完整、结构清晰，适合按章节顺序通读或按主题检索。目前已有 1962 人学习下载，读者可借此梳理架构开发方法、理解架构治理原则与组件关系，并借助中文表述降低原版术语的理解门槛，为实际企业架构项目或认证复习提供参考。
1. 从一份被翻烂的 TOGAF 9.1 中文电子版说起：它到底能解决什么
如果你在企业架构（EA）岗上待过，大概率经历过这种场面：业务方甩过来一张画满框线的“架构图”，问你这套系统怎么演进、模块怎么复用、治理原则在哪，你盯着图看了半天，发现它既没有元模型支撑，也没有 ADM 阶段对应关系，纯靠 PPT 手感拼出来的。这时候你需要的不是再画一张更漂亮的图，而是一套能落地的架构框架——TOGAF 9.1 中文电子版就是干这个的。
这份资源是 The Open Group 发布的 TOGAF 9.1 规范中文译本，覆盖了从引言、核心概念、ADM 方法到架构资产库的完整内容。它解决的核心问题是：把“架构”从个人经验变成可复用、可治理、可迭代的组织能力。适合谁？正在准备架构认证的从业者、需要搭建 EA 治理体系的技术负责人、以及被“架构图没人看”困扰的解决方案工程师。它不是一本读完就能画图的工具书，而是一套需要边查边用的参考框架。
2. 核心概念拆解：架构、ENTERPRISE 与 ABB/SBB 到底怎么区分
2.1 架构的两种含义：别在评审会上用错语境
TOGAF 9.1 中文电子版在核心概念章节里明确了一个容易被忽略的事实：在 TOGAF 语境下，“架构”有两种含义，而且这两种含义在评审会上经常被混用，导致沟通翻车。
第一种含义是“一个系统的正式描述，或指导系统实施的组件层级详细计划”。这种用法出现在你写架构定义文档（Architecture Definition Document）的时候，你是在描述一个目标状态。第二种含义是“组件结构、组件之间相互关系，以及对这些组件的设计和随时间演进的治理原则和指南”。这种用法出现在你谈架构治理、谈演进路线的时候，你是在描述一套持续运作的机制。
常见做法是：在 ADM 的 A 阶段（架构愿景）用第一种含义对齐范围，在 G 阶段（实施治理）用第二种含义约束变更。如果你在 A 阶段就大谈治理原则，业务方会觉得你在讲空话；如果你在 G 阶段还在描述目标组件，实施团队会认为你没有管控力。
提示：TOGAF 采纳但不严格遵循 ISO/IEC 42010:2007 的术语。这意味着你可以用 ISO 的严谨定义去校准，但不必在每份文档里都写一遍标准引用，否则文档会变得又臭又长。
2.2 ENTERPRISE 作为系统：范围界定的第一步
TOGAF 把 ENTERPRISE 视为一个系统。这句话看起来像废话，但在实际项目里，它决定了你的架构工作边界。某公司做数字化转型时，一开始把“企业”等同于“IT 系统”，结果架构工作只覆盖了应用层，数据层和业务层完全脱节。后来按照 TOGAF 的定义，把企业看作一个包含业务、数据、应用、技术四个域的完整系统，才把架构资产库建起来。
具体操作上，你可以用下面这个检查表来界定 ENTERPRISE 范围：
| 维度 | 要问的问题 | 输出物 |
|---|---|---|
| 业务域 | 哪些业务能力在范围内？ | 业务能力地图 |
| 数据域 | 哪些核心数据实体需要治理？ | 数据实体关系图 |
| 应用域 | 哪些应用系统支撑上述业务？ | 应用组合目录 |
| 技术域 | 哪些基础设施是共享的？ | 技术参考模型 |
这个表不是让你一次填完，而是在 ADM 的预备阶段和 A 阶段反复迭代。我一般会把它贴在架构工作坊的墙上，每讨论一个模块就更新一行，避免范围蔓延。
2.3 ABB 与 SBB：架构模块的两种形态
TOGAF 9.1 中文电子版里有一段关于架构模块功能描述的内容，提到了 ABB（Architecture Building Block）和 SBB（Solution Building Block）的区别。这是整个框架里最容易被跳过、但实际工作中最影响复用率的概念。
ABB 是架构层面的功能描述和要求，比如“用户管理模块”应该具备身份认证、权限分配、审计日志等功能。它不绑定具体技术，只定义“做什么”。SBB 是架构功能的具体实现，比如“使用某企业级系统实现的用户管理模块”。它绑定具体产品，定义“怎么做”。
血泪经验是：很多团队在架构评审时直接拿 SBB 当 ABB 用，导致架构被某个具体产品锁死。正确的做法是先在 ABB 层面达成共识，再在 SBB 层面做选型。下面这个对比表可以帮你快速判断：
| 特征 | ABB | SBB |
|---|---|---|
| 抽象层级 | 逻辑层 | 物理层 |
| 是否绑定产品 | 否 | 是 |
| 复用范围 | 跨项目 | 单项目或产品线 |
| 变更成本 | 低 | 高 |
| 典型输出 | 功能需求清单 | 产品配置说明 |
注意：ABB 和 SBB 不是二选一的关系，而是同一架构资产在不同阶段的两种视图。你在架构仓库里应该同时维护两者，并用映射关系连接。
3. 把 TOGAF 9.1 用起来：从 ADM 阶段映射到架构资产库落地
3.1 ADM 阶段与日常工作的映射方法
TOGAF 9.1 中文电子版的核心是 ADM（Architecture Development Method），一个迭代的流程模型。但电子版本身不会告诉你“明天上班该干什么”。我一般会做一张映射表，把 ADM 的九个阶段对应到项目周会、评审节点和交付物上。
| ADM 阶段 | 对应工作场景 | 关键交付物 | 常见耗时 |
|---|---|---|---|
| 预备阶段 | 架构能力评估 | 架构治理框架 | 2-4 周 |
| A 阶段 | 项目启动会 | 架构愿景文档 | 1-2 周 |
| B 阶段 | 业务调研 | 业务架构定义 | 3-6 周 |
| C 阶段 | 系统分析 | 信息系统架构 | 4-8 周 |
| D 阶段 | 技术选型 | 技术架构定义 | 2-4 周 |
| E 阶段 | 方案评审 | 机会与解决方案 | 2-3 周 |
| F 阶段 | 实施规划 | 迁移规划 | 2-4 周 |
| G 阶段 | 上线治理 | 实施治理模型 | 持续 |
| H 阶段 | 复盘迭代 | 架构变更请求 | 持续 |
这张表的价值在于：当老板问你“架构工作什么时候能出东西”时，你可以指着表说“C 阶段结束有信息系统架构，D 阶段结束有技术选型结论”。而不是含糊地说“还在迭代”。
3.2 架构资产库的最小可行结构
TOGAF 强调可复用的架构资产。但电子版不会告诉你资产库该建多大。我的经验是：先建一个最小可行结构，包含四个目录。
# 架构资产库目录结构示例 architecture-repository/ ├── reference-models/ # 参考模型：行业标准、通用模式 │ ├── business-capability-map.md │ └──>## 原则：数据单一来源 ### 陈述 所有核心数据实体必须有且仅有一个权威数据源。 ### 理由 多数据源导致数据不一致，增加集成成本，降低决策可信度。 ### 影响 - 新系统必须通过数据服务访问核心数据，不得直连数据库。 - 数据源变更必须经过架构评审。 - 数据同步方案必须说明冲突解决策略。 ### 验证方式 每季度审计一次数据流向图，检查是否存在绕过数据服务的直连。这个模板的核心是“验证方式”。没有验证方式的原则，在评审会上就是一句空话。有了验证方式，架构师就可以拿着审计结果去推动整改。
提示：原则的数量不要超过 10 条。超过 10 条的原则集，没有人记得住，更没有人会执行。
4. 避坑与排查：TOGAF 9.1 落地时最容易翻车的五个地方
4.1 现象：ADM 阶段全走完，但业务方不认架构文档
原因：架构文档用的是 TOGAF 术语，业务方看不懂。比如“业务架构定义”里写的是“业务能力组件化”，业务方想知道的是“我的审批流程会不会变长”。
解决：每个 ADM 阶段的交付物都配一份“业务影响说明”，用业务语言写清楚“这个阶段决定了什么、不影响什么、需要业务方确认什么”。我一般会在 B 阶段和 C 阶段各做一次业务方评审，而不是等到 E 阶段才拿出来。
4.2 现象：架构资产库建了半年，没人往里存东西
原因：资产库的录入成本太高，架构师宁愿把文件放在自己电脑里。或者资产库没有搜索功能，找东西比重新画还慢。
解决：先降低录入门槛。不要要求每个资产都填完整元模型，先允许上传文件加标签。等积累到一定数量，再逐步补全元数据。另外，资产库必须支持全文搜索，否则就是黑匣子。
4.3 现象：ABB 和 SBB 混用，导致架构被产品锁死
原因：团队在架构设计阶段就直接讨论“用哪个产品”，跳过了 ABB 层面的功能抽象。
解决：在 ADM 的 C 阶段和 D 阶段之间设一个检查点，强制要求先完成 ABB 定义，再进入 SBB 选型。检查点的输出物是一份 ABB 清单，每个 ABB 必须包含功能描述、接口要求和质量属性，但不包含产品名称。
4.4 现象：架构治理委员会开了三次会，什么都没决定
原因：治理委员会的议题太泛，比如“讨论架构演进方向”。没有具体决策事项，讨论就会变成漫谈。
解决：每次治理会只讨论一个具体决策，比如“是否批准某系统直连核心数据库”。会前发材料，会上只做三件事：确认背景、讨论选项、做出决定。决定必须记录在 ADR 里，下次会议回顾执行情况。
4.5 现象：TOGAF 9.1 中文电子版里的术语和公司现有术语冲突
原因：公司内部已经有一套架构术语，比如“中台”“领域服务”，和 TOGAF 的“ABB”“SBB”不是一一对应。
解决：建一张术语映射表，把公司术语和 TOGAF 术语对应起来。不需要强行统一，但需要在架构文档里注明用的是哪套术语。我一般会在文档开头放一张小表，避免读者混淆。
| 公司术语 | TOGAF 对应概念 | 备注 |
|---|---|---|
| 中台 | 共享 SBB 集合 | 不完全等价，中台更强调组织形态 |
| 领域服务 | ABB 的一种实现形态 | 领域服务偏技术，ABB 偏功能 |
| 架构评审 | G 阶段实施治理 | 评审范围不同 |
5. 进阶用法：用 TOGAF 9.1 中文电子版做架构能力评估与迭代验证
5.1 架构能力评估的四个维度
TOGAF 9.1 中文电子版在预备阶段提到了架构能力评估，但没有给出具体操作。我一般会从四个维度做评估，每个维度用 1-5 分打分，然后画出雷达图。
| 维度 | 评估问题 | 1 分表现 | 5 分表现 |
|---|---|---|---|
| 方法 | 是否有明确的 ADM 裁剪方案？ | 完全靠经验 | 有文档化的裁剪指南 |
| 资产 | 架构资产库是否可搜索、可复用？ | 散落在个人电脑 | 有元模型和搜索 |
| 治理 | 架构决策是否有记录和回顾？ | 口头决定 | ADR 完整，定期回顾 |
| 人才 | 团队是否具备架构思维？ | 只会画图 | 能独立做权衡分析 |
这个评估不需要很精确，关键是每季度做一次，看趋势。如果某个维度连续两个季度下降，就需要干预。
5.2 迭代验证：用 ADM 的 H 阶段做闭环
ADM 的 H 阶段（架构变更管理）是很多团队忽略的环节。他们做完 F 阶段（迁移规划）就结束了，没有回到 H 阶段做闭环。结果是：架构变更没有记录，下次遇到同样的问题又从头讨论。
我一般会在 H 阶段做三件事：
## H 阶段闭环检查清单 1. 变更请求是否记录了触发原因？ - 业务变化 / 技术演进 / 合规要求 / 其他 2. 变更是否影响了已有的 ABB 或 SBB？ - 如果影响，是否更新了资产库？ - 如果影响，是否通知了相关项目？ 3. 变更是否产生了新的架构原则或修改了现有原则？ - 如果是，是否更新了原则文档？ - 如果是，是否在下次治理会上宣贯？ 4. 变更是否暴露了 ADM 裁剪方案的问题？ - 如果是，是否调整了裁剪方案？这个清单看起来简单，但坚持做三个迭代周期，架构治理的成熟度会有明显提升。后悔药就是：每次变更都记录，下次就不用重新吵架。
5.3 一个具体技巧：用“架构决策记录”替代“架构评审纪要”
很多团队的架构评审纪要是流水账，写了谁参加、讨论了什么，但没有写决定是什么、为什么这么决定。三个月后翻出来，完全看不懂。
我后来强制要求所有架构决策都写成 ADR，格式如下：
# ADR-002：用户管理模块采用统一身份服务 ## 状态 已批准 ## 背景 三个业务系统各自维护用户数据，导致账号不一致、权限混乱。 ## 选项 1. 各系统继续独立维护，通过同步工具对齐。 2. 建设统一身份服务，各系统通过 API 接入。 3. 采购商业身份管理产品，替换现有模块。 ## 决定 选择选项 2。原因：选项 1 的同步延迟不可接受，选项 3 的迁移成本过高。 ## 后果 - 各系统需要在三个月内完成 API 接入。 - 统一身份服务需要支持至少 10 万用户并发。 - 原有用户数据需要一次性迁移，迁移方案另行制定。这个格式的好处是：半年后任何人翻出来，都能看懂当时的权衡逻辑。从那以后我每次做架构决策都强制走一遍 ADR 流程，哪怕只是选一个日志框架。希望帮到你。
本文还有配套的精品资源，点击获取