ABSD（Architecture-Based Software Design）的核心立场：架构不是设计阶段的一个产物，而是驱动整个开发过程的主线。
六个阶段
ABSD 把软件开发过程划分为六个阶段，架构活动贯穿始终：
架构需求 ──► 架构设计 ──► 架构文档化 ──► 架构复审
│ │
│ ▼
└─────────────────────────────── ◄── 架构实现 ──► 架构演化- 架构需求：捕获需求，明确业务、质量和功能目标；
- 架构设计：通过功能分解、风格选择等手段产出候选架构；
- 架构文档化：把架构决策和结构写成文档，让各方能理解和评审；
- 架构复审：组织相关方评审架构是否满足需求，尽早暴露风险；
- 架构实现：按架构开发系统，用模板和框架约束实现不跑偏；
- 架构演化：系统上线后需求会变，架构随之调整和演进。
注意这是个迭代而非一次性的流程：复审不通过就回到设计，演化中发现新需求就回到需求阶段。
架构驱动：三类需求的组合
ABSD 强调架构设计由三类需求的组合共同驱动：
业务（商业）需求 ┐
质量需求 ├──► 驱动架构设计
功能需求 ┘实践中质量需求往往是架构决策的主要推手——高性能、高可用、可扩展这些属性，靠功能分解是分解不出来的，只能靠架构风格和机制来保障。这也是“架构驱动”和“先功能后架构”做法的根本区别。
三个基础
ABSD 方法建立在三个基础之上：
- 功能的分解：使用基于模块的内聚和耦合技术，把系统分解为合理的构件集合。这是传统结构化方法的遗产，在 ABSD 中用于识别功能结构。
- 通过选择架构风格来实现质量和业务需求：针对具体的质量属性要求（性能、可用性、安全……）选择对应的架构风格与战术，比如分层、管道-过滤器、事件驱动、微内核等，各有各的适用场景。
- 软件模板的使用：用经过验证的模板（参考架构、设计模式、框架骨架）作为设计的起点和约束，既提高效率，也保证实现与架构一致。
视角与视图
架构是复杂的，从不同的视角检查，就会得到不同的视图。ABSD 采用多视图的方法描述架构：
- 逻辑视图：功能结构，构件及其关系；
- 进程视图：并发、同步与通信；
- 开发视图：代码组织、模块划分；
- 物理视图：部署与硬件映射；
- 场景视图：用典型场景串起以上视图，验证架构满足需求。
单一视图必然片面——只看逻辑视图会漏掉并发问题，只看物理视图会看不懂功能结构。多视图互相印证，才能完整回答“这个架构成立吗”。
需求的捕获：用例与场景
ABSD 对两类需求用不同的手段捕获：
| 需求类型 | 捕获手段 | 说明 |
|---|---|---|
| 功能需求 | 用例（Use Case） | 描述系统能做什么，回答“有哪些功能” |
| 质量需求 | 特定场景 | 用「刺激—环境—响应」三要素描述，回答“在多苛刻的条件下表现如何” |
质量场景的三要素：
刺激（Stimulus） 触发系统的事件，如并发请求达到 1 万 QPS
环境（Environment） 发生时的条件，如峰值时段、部分节点故障
响应（Response） 系统应有的反应，如 95% 请求在 200ms 内返回把质量需求写成可验证的场景，架构复审才有依据——否则“高可用”只是一句口号，无法检验架构是否满足。
小结
ABSD 的价值在于把架构从“设计文档里的一张图”变成贯穿需求、设计、复审、实现、演化的过程主线。记住三个抓手即可：用三类需求组合驱动设计，用在功能分解/架构风格/软件模板三个基础上干活，用多视图和可验证的场景来检验架构。