在软件架构设计中，我们一般采用的流程是：
需求分析->架构设计->架构评估
| 阶段 | 核心任务 | 对应的典型方法/活动 | 分类 |
|---|---|---|---|
| ① 需求分析 | 搞清楚“要解决什么问题”和“质量目标是什么”。 | ATAM（作为场景提炼）、DDD（领域分析）、用户故事梳理。 | 分析/诊断方法 |
| ② 架构设计 | 解决“用什么结构去满足这些目标”。 | ADD（属性驱动设计）、模式选择（如微服务）、视图建模（C4/4+1）。 | 设计/构造方法 |
| ③ 架构评估 | 解决“设计好的方案有没有风险，能不能达标”。 | ATAM（作为正式评估）、SAAM（软件架构分析方法）、原型验证、性能测试。 | 评估/检验方法 |
这里我们可以看到，ATAM虽然作为一种架构评估方法，但是常被用来做需求分析，因为里面的“收集并提炼质量属性场景“对于需求分析非常管用。
那么在架构设计阶段，我们就会遇到架构设计方法与架构风格两个概念，这里的区别是什么呢？
如下所示：
| 对比维度 | 架构设计方法 | 架构风格 |
|---|---|---|
| 本质 | 流程、策略、分析框架 | 结构、布局、解决方案模板 |
| 核心问题 | “我如何得到正确的架构？” | “我用哪种结构来解决这个问题？” |
| 产出物 | 需求分析文档、架构决策记录、权衡方案 | 系统分层图、组件拓扑图、通信协议定义 |
| 可变性 | 高（针对不同项目，流程步骤可裁剪） | 低（模板是固定的，只需填充业务细节） |
| 依赖因素 | 严重依赖于人（架构师的经验、组织文化） | 严重依赖于场景（性能、扩展性、团队规模） |
| 典型代表 | ADD、DDD（作为方法时）、ATAM、TOGAF-ADM | 数据流体系风格、调用/返回体系风格、虚拟机体系风格等 |
为了更好的理解上述两个概念，
我们可以分成两个视角看架构过程：
1、架构形态金字塔（从抽象约束到具体模板）
2、独立的设计过程维度（用来产出上面的架构）
架构设计方法：一套步骤和思考框架，用来分析质量属性、业务域，选择合适的架构风格，推导落地成架构模式。例如 ADD 方法、DDD 领域驱动设计、结构化设计方法（SD）、面向对象设计（OOD）、ATAM 架构评估。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。