软件架构方法论：ABSD、DSSA、SAAM、ATAM、CBAM 与 Architectural Thinking
软件架构并不是画出一张组件关系图就结束了。从领域共性提炼、架构设计，到质量属性评估、风险与权衡分析，再到成本收益决策，不同阶段需要解决完全不同的问题。本文系统整理 ABSD、DSSA、SAAM、ATAM、CBAM 与 Architectural Thinking，重点说明它们各自解决什么问题、核心流程是什么、彼此如何衔接，以及如何在真实软件项目中组合使用。
软件架构方法论解决的并不是同一个问题
第一次接触 ABSD、DSSA、SAAM、ATAM、CBAM 时，很容易产生一种错觉：它们似乎都是“设计软件架构的方法”，只是名字不同。
实际上并不是这样。
这些方法处于软件架构工作的不同位置：有的方法负责设计架构，有的方法负责从整个领域中提炼可复用参考架构，有的方法负责评估架构，还有的方法进一步把架构决策转换为经济决策。
SEI 在长期的软件架构研究中形成了从 Architecture-Based Development、SAAM、ATAM 到 CBAM 等一系列架构中心方法；DSSA 则来自领域工程与系统化软件复用方向。IBM 的 Architectural Thinking 又提供了另一种偏向“统一架构思考过程和架构制品”的企业实践视角。
先建立一个整体认识：
| 方法 | 全称 | 核心问题 | 主要产物 |
|---|---|---|---|
| ABSD | Architecture-Based Software Design / Development 语境 | 一个具体系统如何围绕架构进行设计和开发 | 架构需求、概念架构、构件、视图、架构文档 |
| DSSA | Domain-Specific Software Architecture | 一个领域中的一类系统如何形成可复用架构 | 领域模型、共性/可变性模型、领域参考架构、可复用资产 |
| SAAM | Software Architecture Analysis Method | 架构面对具体变化场景时是否容易修改 | 场景、变化影响、构件交互影响、架构评价 |
| ATAM | Architecture Tradeoff Analysis Method | 多个质量属性之间如何分析风险与权衡 | Utility Tree、风险、非风险、敏感点、权衡点 |
| CBAM | Cost Benefit Analysis Method | 多个架构策略都可行时，哪一个更值得投资 | 收益、成本、进度、风险、架构投资优先级 |
| AT | Architectural Thinking | 架构师如何稳定、系统地思考并表达架构 | 需求、架构决策、组件模型、运行模型、架构视图等 |
它们可以形成一个很有用的认知框架：
flowchart LR
DOMAIN[领域知识与既有系统] --> DSSA[DSSA<br/>领域工程与参考架构]
DSSA --> REUSE[领域模型<br/>参考架构<br/>可复用资产]
REQ[业务目标<br/>功能需求<br/>质量属性<br/>约束] --> AT[Architectural Thinking<br/>组织架构思考]
REUSE --> DESIGN[ABSD / ABD<br/>架构设计]
AT --> DESIGN
DESIGN --> ARCH[候选软件架构]
ARCH --> SAAM[SAAM<br/>场景分析]
ARCH --> ATAM[ATAM<br/>质量属性权衡]
SAAM --> IMPROVE[架构改进]
ATAM --> IMPROVE
IMPROVE --> ARCH
ATAM --> CBAM[CBAM<br/>经济分析]
CBAM --> ROADMAP[架构投资与演进路线]
这张图不是任何标准规定的强制流程，而是把这些方法放到实际项目生命周期中的一种组合方式。最关键的是理解它们各自承担的职责，而不是试图选一个方法包打天下。
先解决两个很容易混淆的名称问题
ABSD、ABD 与 Architecture-Based Development
国内的软件架构教材和系统架构设计师考试资料通常使用 ABSD（Architecture-Based Software Design / Development） 来描述“基于架构的软件开发”，并经常总结为：
架构需求 → 架构设计 → 架构文档化 → 架构复审 → 架构实现 → 架构演化。
同时强调三个基础：功能分解、通过架构风格满足质量与商业需求、使用软件模板。
但回到 SEI 的原始文献，会看到两个更准确的名称。
1999 年 Bass 和 Kazman 发布了 Architecture-Based Development，讨论以软件架构为中心进行系统开发，包括架构需求、设计、文档、评价、实现和维护。
2000 年 Bachmann、Bass 等人又正式提出 Architecture Based Design（ABD）。ABD 关注产品线或长生命周期系统的高层软件架构设计，并以功能需求、质量需求和商业需求为输入，输出概念架构以及约束构件实现方式的软件模板。
因此本文会沿用国内更常见的 ABSD 说法，但需要知道：
国内教材中的 ABSD 是一种经过课程体系重新组织后的“基于架构的软件开发方法”表述；SEI 原始资料中的 Architecture-Based Development 和 ABD 与它高度相关，但名称和过程边界并非完全相同。
理解这个差异，遇到英文原始资料时就不会产生“为什么搜不到 ABSD 官方标准”的困惑。
AT 与 ATAM 完全不是一回事
ATAM 是 SEI 正式提出的 Architecture Tradeoff Analysis Method，有明确的方法、步骤和评价产物。
而本文所说的 AT 指 Architectural Thinking。
IBM 确实存在名为 Architectural Thinking 的课程和能力体系，其目标是通过共同的思考过程以及共同的架构制品，让架构师能够以可重复、一致的方式开发和交流 IT Architecture。IBM 列出的能力包括 Architecture Requirements、Non-functional Requirements、Architecture Decisions、Component Models、Operational Models、Architecture Principles、Technical Reviews 等。
不过，“AT”并不是像 SAAM、ATAM、CBAM 那样由 SEI 定义并具有统一国际标准流程的缩写。国内一些架构课程和技术文章会把 Architectural Thinking 简称为 AT，并进一步归纳为“需求驱动 + 多视角”的架构思维框架。
因此后面谈 AT 时，更准确的理解应该是：
Architectural Thinking 是一种组织架构思考、决策、建模和沟通的方法框架，而不是一套与 ATAM 同性质的标准化架构评价算法。
ABSD：让架构真正驱动软件开发
从“写功能”转向“先确定系统骨架”
传统软件开发容易形成这样的路径：
1 | |
问题在于，性能、安全、可靠性、可修改性等质量属性往往不是某一个类、某一个方法能够在开发后期补上的，它们大量取决于早期的架构决策。
Architecture-Based Development 的思想正好相反：除了普通功能需求，还需要识别架构需求（Architectural Requirements），让这些需求参与架构设计，并让架构继续指导文档、评价、实现和演化。
例如一个结算系统不仅有：
1 | |
还可能有：
1 | |
后一组要求往往比“有没有一个 SettlementController”更能决定系统最终应该长成什么样。
ABSD 的三个重要基础
国内 ABSD 教材通常将其概括为三个基础。
功能分解
架构仍然需要首先回答：
系统到底由哪些职责组成？
例如：
1 | |
然后继续递归细化：
1 | |
功能分解仍然遵循高内聚、低耦合、职责清晰等基本设计原则。
但仅仅做功能分解是不够的。
通过架构风格满足质量属性与商业要求
假设系统存在：
1 | |
那么就可能进一步得到：
1 | |
其因果链应该是：
1 | |
而不是：
1 | |
SEI 的 ABD 明确强调，设计需要同时满足 functional、quality 和 business requirements，并理解实现这些要求所依赖的 architecture mechanisms。
软件模板
ABD 的另一个重要输出是 Software Template。模板并不仅仅意味着“代码模板”，而是规定某一类构件应该如何实现、如何使用共享服务、需要承担哪些公共责任。
放到现代 Java 企业应用中，可以理解成：
1 | |
它的价值在于：
架构不只告诉你“有哪些组件”，还告诉开发者“这种组件应该怎样正确地活在整个系统里”。
ABSD 的六个过程
在国内常见的 ABSD 模型中，整个过程被组织为六个阶段。
flowchart LR
A[架构需求] --> B[架构设计]
B --> C[架构文档化]
C --> D[架构复审]
D --> E[架构实现]
E --> F[架构演化]
D -.发现问题.-> B
F -.新需求.-> A
架构需求
这一阶段不是把全部需求重新做一遍，而是找出真正能够影响架构的需求。
通常包括：
- 业务目标；
- 核心功能；
- 质量属性；
- 技术和组织约束；
- 外部系统；
- 系统边界；
- 关键场景。
例如“用户可以查询结算单”通常不会单独决定架构，但“结算历史必须可长期审计”“核心任务失败后必须可以恢复”“多个业务线具有不同结算规则”就很可能属于 Architecturally Significant Requirements。
架构设计
把架构需求映射为：
1 | |
这一阶段真正需要回答的是：
为什么这样分？
为什么这里使用异步？
为什么这里必须隔离？
为什么这里允许共享数据库，而那里不允许？
架构图只是结果，决策逻辑才是架构设计的核心。
架构文档化
好的架构不应该只存在于架构师的大脑里。
需要把它表达成多个视图，例如：
1 | |
并记录重要的 Architecture Decision。
否则半年之后很容易出现经典场面：
“这个 Kafka 为什么存在？”
团队面面相觑，最后只能回答：“听说以前架构师要求的。”
架构复审
复审的目的不是看图画得漂不漂亮，而是提前发现架构风险。
典型问题包括：
1 | |
SAAM 和 ATAM 等评价方法可以在这一阶段进一步发挥作用。
架构实现
架构开始从概念变成真实系统：
1 | |
架构实现还存在一个很容易被忽略的问题：
实际代码是否仍然符合架构？
如果架构规定：
1 | |
但开发三个月以后变成：
1 | |
那么文档里的架构已经不再是系统的真实架构。
架构演化
软件架构不是一次性制品。
需求改变、基础设施改变、流量模型改变、组织边界改变，都可能推动架构演化。Architecture-Based Development 本身也把架构维护视为架构中心开发过程的一部分。
所以真正的过程应该是：
1 | |
而不是只改代码，不改架构。
DSSA：从“做一个系统”提升到“做一个领域”
ABSD 面对的通常是具体系统，而 DSSA（Domain-Specific Software Architecture） 把视野放得更大：
如果公司反复开发同一领域中的相似系统，能不能先研究这一族系统的共同规律，再建立一套领域参考架构？
SEI 在 1993 年发布的 DSSA Process Life Cycle 报告描述了早期 DARPA/GTE DSSA 项目形成的领域特定软件架构生命周期。DSSA 背后的重要目标正是通过领域知识和架构资产实现更系统的软件复用。
DSSA 关注的是“一族系统”
例如公司存在：
1 | |
传统开发容易变成：
1 | |
DSSA 会换一个问题：
这些系统到底哪些东西是共同的，哪些东西真正不同？
于是可以得到：
| 类型 | 示例 |
|---|---|
| 共性 | 结算主体、结算周期、结算单、结算明细、应收应付、费用、对账、审核 |
| 可变性 | 结算规则、费用规则、结算对象、审批流程、数据来源、付款策略 |
这一步非常重要。
DSSA 的核心并不是“把公共代码抽成 common.jar”，而是寻找：
Commonality（共性） + Variability（可变性）。
领域工程同样强调通过已有系统、领域知识和各种需求资料发现领域中的 commonality、variability 和 dependency，并据此建立领域模型。
领域分析：这个领域到底是什么
Domain Analysis 主要研究问题空间。
输入可能来自：
1 | |
分析的重点包括：
1 | |
例如结算领域可能形成：
1 | |
这时候还不能急着说：
1 | |
因为领域分析是在研究问题空间，还没有必要过早绑定具体技术实现。
领域设计：把领域知识转化为参考架构
Domain Design 开始进入解决方案空间。
研究需要哪些模块：
1 | |
然后识别模块之间的依赖和交互机制。
例如：
flowchart LR
SOURCE[业务数据源] --> COLLECT[数据归集]
COLLECT --> CORE[结算核心]
RULE[规则引擎] --> CORE
FEE[费用模块] --> CORE
CORE --> BILL[结算单]
BILL --> RECON[对账]
RECON --> APPROVAL[审核]
APPROVAL --> PAYMENT[收付款]
EXT[业务扩展点] -.策略扩展.-> RULE
领域设计的目标不是得到某一个系统的唯一结构，而是形成能够容纳多个领域变体的参考架构。
相关领域工程研究通常把这一阶段的目标描述为设计一个或一组 DSSA，并规定它们的选择、应用方式以及公共/可变构件。
领域实现：把参考架构变成可复用资产
只有参考架构图，还不能产生真正的复用价值。
领域实现还需要把架构落成：
1 | |
例如：
1 | |
并明确变化点：
1 | |
具体业务实现自己的策略：
1 | |
于是：
1 | |
这才是 DSSA 所追求的架构级复用。
DSSA 和 DDD 并不是一回事
DSSA 和 Domain-Driven Design 很容易放到一起理解，因为二者都强调“领域”。
但关注点不同。
DDD 更关注：
1 | |
DSSA 更关注：
1 | |
可以粗略记成：
DDD 主要解决复杂业务怎样建模；DSSA 主要解决同一领域的一族系统怎样进行系统化架构复用。
实际工程完全可以使用 DDD 建模领域，再通过 DSSA/Product Line 思想沉淀跨产品的参考架构，两者并不冲突。
SAAM：不要问“架构好不好”，要拿场景来试
设计完架构之后，一个非常麻烦的问题出现了：
怎么证明这个架构是好的？
“结构清晰”“高内聚低耦合”“扩展性不错”都非常主观。
SAAM（Software Architecture Analysis Method）解决这个问题的突破口是：
使用具体场景去测试架构。
SEI 将 SAAM 视为其最早的软件架构分析方法之一，并指出 SAAM 引入了 Quality Attribute Scenario，通过具体变化测试架构对于可修改性及其他质量属性的支持能力；它也直接推动了后来的 ATAM。
把抽象质量属性变成具体场景
例如说：
系统必须具有良好的可修改性。
几乎没有分析价值。
改成：
新增一种结算业务时，不修改结算核心，只增加一个新的规则实现即可接入。
这就可以分析。
再比如：
1 | |
它们都是可以真正“打到架构上”的场景。
Direct Scenario 与 Indirect Scenario
在演进后的 SAAM 场景分析中，场景可以进一步区分为：
Direct Scenario
现有架构能够直接支持，不要求结构性修改。
例如：
1 | |
这种变化已经被架构设计预见。
Indirect Scenario
为了支持这个场景，需要修改现有架构元素。
例如：
1 | |
SEI 的场景化架构分析文献明确使用了 direct / indirect 的区分：如果场景需要改变现有构件或连接，就属于 indirect scenario，并应进一步描述变化范围和成本。
Scenario Interaction：比“改了几个类”更重要
假设存在三个变化：
1 | |
结果发现它们都需要修改：
1 | |
这就是值得警惕的架构信号。
因为原本看起来完全不同的业务变化，全部集中打到一个构件上，意味着这个构件可能承担了过多职责。
因此 SAAM 不只关心：
一个场景需要修改多少地方？
还关心：
多个不同场景是不是总在修改同一个地方？
这就是 Scenario Interaction 的价值。
SAAM 的步骤为什么有“五步”和其他版本
早期 SAAM 文献给出的五项主要活动是：
- 描述领域典型的功能划分；
- 将功能划分映射到架构结构；
- 选择需要评价的质量属性；
- 选择能够测试这些质量属性的具体任务；
- 评价架构对各任务的支持程度。
随着实践发展，SEI 后来的 scenario-based analysis 又逐渐形成更加场景化的执行方式：
1 | |
SEI 自己也明确说明，随着实际架构分析经验增加，SAAM 的 prescribed steps 发生过演进，所以不同教材看到的流程数量不完全一致并不奇怪。
真正应该记住的不是“五还是六”，而是：
场景 → 映射到架构 → 分析变化影响 → 分析场景之间的交互 → 判断架构对质量属性的支持。
SAAM 的优势和边界
SAAM 特别适合：
1 | |
它最大的优点是非常具体。
但它也有明显边界：当系统同时存在性能、安全、可用性、可修改性等大量质量属性，而且这些属性之间还存在冲突时，仅仅分析“某个变化要修改多少构件”已经不够。
这正是 ATAM 要解决的问题。
ATAM：真正困难的是质量属性之间的 Tradeoff
软件架构不存在无代价的“全都要”。
例如：
1 | |
1 | |
1 | |
1 | |
因此真正的软件架构问题通常不是：
能不能实现？
而是：
为了获得某项质量属性，需要牺牲什么？
这就是 ATAM（Architecture Tradeoff Analysis Method）的核心。
SEI 将 ATAM 定义为一种根据 Quality Attribute Goals 评价软件架构的方法，它不仅寻找单个质量属性是否满足要求，还分析不同质量属性之间如何相互影响，从而暴露可能威胁业务目标的架构风险。
ATAM 从 Business Driver 开始
ATAM 有一个很重要的特点：
不从技术开始，而从 Business Driver 开始。
例如：
1 | |
然后映射：
1 | |
于是建立：
1 | |
架构评价终于不再是：
“我感觉 Redis + Kafka + Kubernetes 很先进。”
而变成：
“这个架构决策到底支持了哪个业务目标？”
Utility Tree：给质量属性建立层次
ATAM 中很有代表性的制品是 Utility Tree（效用树）。
例如：
1 | |
这里最重要的变化是：
1 | |
不再只是一个抽象单词，而是继续落到：
1 | |
形成可以分析的具体场景。
SEI 的 ATAM 流程要求将性能、可用性、安全、可修改性、可用性等系统 utility 一直细化到场景级，并进行优先级排序。
ATAM 的九个步骤
SEI 当前公开的 ATAM 方法包含九个步骤。
1. Present the ATAM
说明：
1 | |
这一步看起来像会议开场，其实非常重要。
如果业务方认为这是“架构师技术评审会”，业务目标很可能根本进不了评价过程。
2. Present Business Drivers
由项目负责人、客户或业务代表说明：
1 | |
这里确定的是整个评价过程的方向。
3. Present Architecture
架构师描述当前候选架构，并重点解释：
架构如何支持这些 Business Drivers？
而不是从第一页开始念组件名称。
4. Identify Architectural Approaches
识别重要架构策略，例如：
1 | |
此时先找出来，不急着立刻下结论。
5. Generate Quality Attribute Utility Tree
把业务目标转化为质量属性，再转换为场景并排序。
flowchart TD
U[Utility]
U --> A[Availability]
U --> P[Performance]
U --> M[Modifiability]
U --> S[Security]
A --> A1[故障恢复场景]
P --> P1[高负载场景]
M --> M1[新增业务类型场景]
S --> S1[越权访问场景]
6. Analyze Architectural Approaches
使用高优先级场景分析架构策略，识别：
1 | |
7. Brainstorm and Prioritize Scenarios
让更多干系人参与场景生成。
因为架构师自己写出来的场景，很可能天然偏向自己的设计。
运维、安全、开发、产品、业务负责人看到的风险往往完全不同。
8. Analyze Architectural Approaches Again
使用干系人共同产生并排序后的高优先级场景，再次评价架构。
这一轮通常会暴露之前没有看到的问题。
9. Present Results
最终产出不是：
1 | |
而是一套结构化知识：
1 | |
SEI 对 ATAM 输出的描述正包括这些内容，并特别强调评价的价值在于尽早识别风险、澄清质量属性需求、改善架构文档以及形成架构决策依据。
Risk 与 Non-Risk
假设：
1 | |
当前设计：
1 | |
那么：
1 | |
就可能成为一个 Risk。
反过来，如果已经有：
1 | |
并且这些设计能够支持对应场景，就可能被记录为 Non-Risk。
Non-Risk 并不是说：
永远不会出问题。
它的意思更接近：
在当前需求和假设条件下，这项架构决策有充分理由被认为能够支持目标质量属性。
Sensitivity Point
Sensitivity Point（敏感点）表示：
某个架构参数或架构决策发生变化时，会显著影响某个质量属性。
例如：
1 | |
或者：
1 | |
这些地方通常值得重点测试和监控。
Tradeoff Point
Tradeoff Point 更进一步：
某个架构决策同时影响多个质量属性，而且这些影响之间可能相互冲突。
例如缓存：
1 | |
又比如拆微服务：
1 | |
这才是 ATAM 中“Tradeoff”真正有价值的地方。
SAAM 和 ATAM 到底是什么关系
SEI 对自身架构评价方法的历史总结非常明确：SAAM 是较早的场景化软件架构分析方法，并直接推动了 ATAM；ATAM 则进一步面向一组质量属性进行架构评价。
因此可以这样理解：
1 | |
而 ATAM：
1 | |
二者并不是：
1 | |
这么简单。
SAAM 的思维依然非常有用，尤其是在可修改性、演化影响和架构方案比较方面；ATAM 更适合复杂系统中的多质量属性权衡和系统性风险识别。
可以粗略记成：
SAAM 重点问“这个场景来了要改哪里”；ATAM 进一步问“这些架构决策对不同质量属性分别有什么影响，彼此又有什么冲突”。
CBAM：技术上都能做，钱应该投在哪里
ATAM 可以告诉你：
1 | |
但管理层最后还是要问一句：
所以到底选哪个？
这时候仅仅讨论技术 Tradeoff 已经不够了。
因为企业的软件架构永远受制于：
1 | |
这就是 CBAM（Cost Benefit Analysis Method） 的问题空间。
SEI 对 CBAM 的定义非常明确：它通过分析架构决策带来的收益、真实开发成本、风险和进度影响，帮助组织在有限资源下比较多个架构选项。
ATAM 解决技术权衡，CBAM 增加经济权衡
SEI 在研究 ATAM 与 CBAM 集成时指出：
- ATAM 提供技术 Tradeoff 和 Risk 的分析框架；
- 但 ATAM 本身不负责经济权衡；
- CBAM 将优先级、成本和收益加入架构决策；
- 最终可以把架构决策纳入更长期的软件设计和演进路线。
关系可以表示为：
1 | |
为什么只比较 Cost 不够
假设有三个方案：
1 | |
单纯问：
1 | |
没有意义。
应该问：
1 | |
CBAM 强调的正是：
不能只分析 Architecture Cost，还要分析 Architecture Benefit。
SEI 甚至特别指出，企业往往只计算“建设系统的成本”，却忽略维护和升级成本，而架构选择真正需要面对的是整个生命周期中的资源竞争。
CBAM 的六个步骤
SEI 当前介绍的 CBAM Process 包含六步。
1. Choose Scenarios and Architectural Strategies
选出重要质量属性场景，再提出能够改善这些场景的架构策略。
例如：
1 | |
2. Assess Quality Attribute Benefits
评价不同策略对质量属性的改善程度。
关注：
1 | |
而不是简单问：
谁用了更新的技术？
3. Quantify Benefits
进一步将策略带来的收益结构化、量化。
这里的“量化”并不意味着一定能得到绝对精确的金额，而是为了让不同方案能够在统一标准下比较。
4. Quantify Cost and Schedule Implications
评估：
1 | |
这是很多“纯技术架构设计”最容易漏掉的地方。
5. Calculate Desirability
把：
1 | |
综合起来，比较不同 Architecture Strategy 的相对吸引力。
可以使用类似：
[
Desirability_i \propto \frac{Benefit_i}{Cost_i}
]
这样的思路帮助理解，但实际 CBAM 并不是简单地“收益除以成本就结束”，还需要考虑进度、风险、不确定性以及不同干系人的效用判断。
6. Make Architectural Design Decisions
最终确定：
1 | |
并形成：
1 | |
需要特别强调：
CBAM 并不是替管理者做决定。
它的价值是让成本、收益和不确定性显性化，让架构投资从“谁声音大听谁的”变成一个更理性的决策过程。SEI 对 CBAM 的描述同样强调，它帮助组织形成 informed decision，而不是自动产生唯一正确答案。
Architectural Thinking：让架构设计成为一种可重复的思考过程
前面的几个方法都有非常明确的问题：
1 | |
Architectural Thinking 更像站在它们上面问：
架构师到底应该如何系统地收集信息、组织问题、形成决策并表达架构？
IBM 对 Architectural Thinking 的描述强调：
使用共同的思考过程和共同的架构制品，让 IT Architecture 的开发具备 repeatable 和 consistent 的特点，并让架构师能够有效协作。
架构不是“一张图”，而是一组相互关联的制品
IBM 的相关 Architect Assistant 文档列出的架构制品非常具有代表性，包括：
1 | |
从这里可以发现一个非常重要的变化：
1 | |
而应该是：
1 | |
先定义 Scope
Architectural Thinking 的第一个实际问题通常不是：
用 Spring Boot 还是 Go？
而是：
我们到底正在设计什么？
可以通过：
1 | |
明确系统目标和边界。
例如：
flowchart LR
USER[财务人员] --> SETTLEMENT[结算平台]
ERP[ERP] --> SETTLEMENT
ORDER[订单系统] --> SETTLEMENT
SETTLEMENT --> PAYMENT[资金系统]
SETTLEMENT --> BI[数据分析平台]
System Context 的意义在于先确定：
1 | |
IBM 的架构制品体系同样把 Business Challenge 和 System Context 用于表达 solution scope。
再整理 Requirement
需求至少需要区分：
1 | |
其中真正决定架构形状的，往往是 Non-Functional Requirements。
例如：
1 | |
第二条可能会推动：
1 | |
再比如：
1 | |
它可能推动：
1 | |
同样一个功能，不同质量要求完全可能产生不同架构。
从 Logical Model 到 Physical Model
架构思考中非常重要的一项能力，就是不要过早跳到产品名称。
逻辑层先考虑：
1 | |
然后物理层才决定：
1 | |
这样，架构决策的逻辑是：
1 | |
而不是：
1 | |
国内一些 Architectural Thinking 教学资料会进一步使用“业务/应用、逻辑技术、物理技术、功能、运行”等多视角帮助组织这一思考过程。这个“架构立方体”更适合作为教学模型理解，而不应该误认为是 IBM 或 SEI 统一规定的标准模型。
Architectural Decision 才是架构最值得保留的部分
真正值得记录的不是：
1 | |
而是：
1 | |
这就是 Architecture Decision Record 背后的思维。
几年之后，技术名称可能变化：
1 | |
但：
1 | |
才是真正能够被复用的架构知识。
IBM 的 Architectural Thinking 能力体系也把 Architecture Decision、Architecture Principles、Architecture Life Cycle 和 Technical Reviews 列为核心能力。
从多个 View 表达同一个 Architecture
不同干系人关心的根本不是同一件事。
业务人员关心：
1 | |
开发人员关心：
1 | |
DBA 关心：
1 | |
运维人员关心：
1 | |
安全人员关心：
1 | |
所以不应该试图用一张“大杂烩图”服务所有人。
正确方式是：
1 | |
IBM Research 对 Architectural Thinking 与 Modeling 的研究同样关注如何收集、组织架构信息，将这些信息转换成可行的模型，并保持各个架构工作制品之间的一致性。
把六种方法放进同一个真实架构问题
假设一个企业已经存在：
1 | |
现在计划逐步形成统一的结算平台。
系统同时面对：
1 | |
不用某一个方法硬套整个问题，而是可以分层使用。
第一步：使用 DSSA 看整个“结算领域”
先不要讨论服务怎么拆。
先分析多个系统：
1 | |
找出共同部分：
1 | |
以及变化部分：
1 | |
得到：
1 | |
这一步解决：
哪些东西应该做成平台能力，哪些东西必须留给具体业务扩展？
第二步：使用 Architectural Thinking 整理具体项目
确定新平台：
1 | |
再画：
1 | |
识别：
1 | |
然后整理：
1 | |
建立：
1 | |
解决：
我们到底在设计什么，以及如何让不同干系人理解同一套架构？
第三步：使用 ABSD 将需求落成架构
根据：
1 | |
开始设计：
1 | |
并确定：
1 | |
之后完成：
1 | |
解决：
这个具体系统应该如何从需求走向实现？
第四步：使用 SAAM 检查变化能力
设计场景：
1 | |
映射到架构：
1 | |
如果所有场景都修改：
1 | |
就需要重新检查模块职责。
解决：
未来真实变化发生时，这个架构到底要改多少？
第五步：使用 ATAM 做质量属性 Tradeoff
把高优先级质量属性放进 Utility Tree：
1 | |
然后分析：
1 | |
找到：
1 | |
例如：
1 | |
或者：
1 | |
解决：
这个架构在哪些地方存在真正的质量属性风险？
第六步：使用 CBAM 决定架构投资顺序
假设识别出三个潜在改进：
1 | |
三个都可能有价值，但资源有限。
于是分析：
1 | |
最终形成：
1 | |
解决：
哪些架构改造值得现在花钱做？
这时候整个流程就连起来了：
flowchart TD
A[DSSA<br/>发现领域共性与可变性]
B[Architectural Thinking<br/>整理需求、边界、决策与视图]
C[ABSD<br/>设计具体软件架构]
D[SAAM<br/>使用变化场景测试架构]
E[ATAM<br/>分析质量属性风险与权衡]
F[CBAM<br/>分析成本收益并确定投资顺序]
G[架构实现与持续演化]
A --> B
B --> C
C --> D
C --> E
D --> C
E --> C
E --> F
F --> G
G --> B
再次强调：这是一种工程组合方式，不是规定必须依次执行的官方流程。
六种方法应该怎么选
真正做项目时，不需要把六套方法全部完整跑一遍。
判断当前问题是什么即可。
| 当前问题 | 更适合的方法 |
|---|---|
| 正在从需求设计一个具体系统 | ABSD / Architecture-Based Development |
| 公司反复建设同一领域中的相似产品 | DSSA |
| 想知道未来某个变化会修改哪些架构元素 | SAAM |
| 系统存在多个重要质量属性，需要系统评价 | ATAM |
| 性能、可用性、安全、可修改性存在冲突 | ATAM |
| 已经有多个技术可行方案，不知道哪个更值得投入 | CBAM |
| 需要形成统一的架构分析、建模和文档方式 | Architectural Thinking |
| 希望建立领域级平台或产品线 | DSSA + ABSD |
| 重构大型遗留系统 | Architectural Thinking + SAAM/ATAM |
| 制定长期架构演进路线 | ATAM + CBAM |
还可以按问题范围来记：
1 | |
几个特别容易出现的误区
把 ABSD 理解成“先设计完所有架构再写代码”
Architecture-Based Development 强调 Architecture-Centric，并不等于 Big Design Up Front。
架构设计和架构评价完全可以随着迭代持续进行：
1 | |
关键不是“一开始设计多少”，而是：
影响全局的关键决策不能一直拖到编码过程中随机产生。
把 DSSA 理解成公共组件库
如果做完 DSSA 最终只有：
1 | |
那基本没有触及它真正的价值。
DSSA 应该沉淀的是：
1 | |
公共代码只是最后可能产生的资产之一。
把 SAAM 理解成代码影响分析
SAAM 分析的是 Architecture Impact。
它关心：
1 | |
而不是：
1 | |
一个架构组件可能对应几百个类，也可能只有几个类。
把 ATAM 做成技术方案评审会
如果 ATAM 会议从：
1 | |
开始，那么方向基本已经跑偏。
正确链路应该是：
1 | |
技术产品只是 Architecture Approach 的实现选择之一。
把 CBAM 当成一个精确的财务公式
架构收益往往无法做到像证券交易一样精确估值。
CBAM 的意义不是制造“精确到小数点后两位”的假确定性，而是：
1 | |
不确定性本来就是架构决策的一部分。SEI 的 CBAM 材料同样明确将 uncertainty 和 risk 纳入架构经济分析。
把 Architectural Thinking 当成统一国际标准
IBM 确实存在 Architectural Thinking 的正式学习和能力体系，也有长期的架构建模实践。
但如果在考试、论文或正式架构文档中出现：
1 | |
最好进一步说明：
1 | |
以及具体采用的是哪一个组织或课程体系中的定义。
不能默认：
1 | |
像：
1 | |
一样拥有唯一、统一的方法定义。
从历史演进看这些方法为什么会出现
把时间线放在一起，也能帮助理解它们各自解决的问题。
timeline
title 软件架构方法演进中的几个重要节点
1993 : SEI 发布 DSSA Process Life Cycle 报告
1994 : SAAM 成为 SEI 早期场景化架构分析方法
1998 : ATAM 相关方法形成
1999 : SEI 发布 Architecture-Based Development
2000 : SEI 发布 Architecture Based Design Method
2001-2003 : CBAM 逐步形成并与 ATAM 集成
2006 : IBM Research 发表 Architectural Thinking 与建模相关研究
DSSA 代表的是一个早期而重要的问题：
软件能不能从“代码复用”进一步走向“领域架构复用”？
SAAM 解决的是：
架构还没有完全实现时，怎样提前判断它面对变化会不会很痛苦？
ATAM 将问题扩大为：
怎样同时分析性能、可用性、安全、可修改性等质量属性，以及它们之间的 Tradeoff？
Architecture-Based Development 和 ABD 则进一步关注：
怎样让架构真正成为开发生命周期的中心，而不只是项目启动时的一张图？
CBAM 又把架构向业务决策推进了一步：
技术上可以做很多事情，但有限的钱和时间到底应该投在哪里？
Architectural Thinking 关注的则是组织能力：
如何让不同架构师使用相对稳定的思考过程、模型和制品进行架构工作？
这些方法并不是互相替代，而是在不断填补软件架构工程中的不同空白。DSSA、SAAM、ATAM、Architecture-Based Development/ABD 和 CBAM 的历史资料均能够看到这种从复用、设计、评价到经济决策的演进轨迹。
最终应该掌握的不是流程，而是六种不同的架构思维
把所有方法背成步骤，很容易考试结束之后一起忘掉。
真正有用的是保留六个问题。
ABSD
面对具体系统时问：
哪些业务、质量和约束需求真正决定架构？应该如何把它们逐步转化成构件、连接、视图和实现约束？
核心：
1 | |
DSSA
面对多个相似系统时问：
这里面哪些是领域稳定共性，哪些是变化点，能否形成一套长期可复用的领域架构？
核心：
1 | |
SAAM
面对一个候选架构时问：
如果这个变化明天真的来了，要修改哪些地方？
核心：
1 | |
ATAM
面对复杂质量属性时问：
为了性能、可用性、安全、可修改性分别做了什么，这些决策之间又会产生哪些 Risk 和 Tradeoff？
核心：
1 | |
CBAM
面对多个候选改造时问：
技术上都能做，但哪一项架构投资能够在有限资源下产生更高价值？
核心：
1 | |
Architectural Thinking
面对整个架构工作时问：
有没有一套稳定方式，把业务问题、需求、模型、决策、运行环境和风险组织起来，让其他人真正理解这套架构？
核心：
1 | |
总结
ABSD、DSSA、SAAM、ATAM、CBAM 和 Architectural Thinking 看起来是一堆缩写，实际上代表的是软件架构中六种不同层次的问题。
DSSA 把视野提升到整个领域，通过分析共性和可变性形成领域参考架构；ABSD 把业务、功能和质量需求逐渐转化为具体系统架构，并让架构贯穿设计、实现和演化；SAAM 使用场景检验架构面对变化时的可修改能力；ATAM 将业务目标、质量属性、架构策略以及 Risk、Sensitivity Point、Tradeoff Point 联系起来；CBAM 再把成本、收益、进度和风险引入决策，使架构设计进入经济层面；Architectural Thinking 则贯穿整个过程，帮助架构师建立稳定的需求、决策、建模、视图和沟通体系。
如果把它们压缩成一条最容易记住的主线，就是：
1 | |
软件架构真正困难的地方，从来不是知道多少中间件，也不是能画多复杂的图。
真正的架构能力是能够建立完整的因果链：
1 | |
当这些问题能够被持续回答、记录、验证和修正时，架构才从“技术栈组合图”真正变成了工程方法。