软件架构风格与软件架构设计方法

在软件架构设计中，我们一般采用的流程是：

需求分析->架构设计->架构评估

阶段	核心任务	对应的典型方法/活动	分类
① 需求分析	搞清楚“要解决什么问题”和“质量目标是什么”。	ATAM（作为场景提炼）、DDD（领域分析）、用户故事梳理。	分析/诊断方法
② 架构设计	解决“用什么结构去满足这些目标”。	ADD（属性驱动设计）、模式选择（如微服务）、视图建模（C4/4+1）。	设计/构造方法
③ 架构评估	解决“设计好的方案有没有风险，能不能达标”。	ATAM（作为正式评估）、SAAM（软件架构分析方法）、原型验证、性能测试。	评估/检验方法

 

这里我们可以看到，ATAM虽然作为一种架构评估方法，但是常被用来做需求分析，因为里面的“收集并提炼质量属性场景“对于需求分析非常管用。

 

那么在架构设计阶段，我们就会遇到架构设计方法与架构风格两个概念，这里的区别是什么呢？

如下所示：

对比维度	架构设计方法	架构风格
本质	流程、策略、分析框架	结构、布局、解决方案模板
核心问题	“我如何得到正确的架构？”	“我用哪种结构来解决这个问题？”
产出物	需求分析文档、架构决策记录、权衡方案	系统分层图、组件拓扑图、通信协议定义
可变性	高（针对不同项目，流程步骤可裁剪）	低（模板是固定的，只需填充业务细节）
依赖因素	严重依赖于人（架构师的经验、组织文化）	严重依赖于场景（性能、扩展性、团队规模）
典型代表	ADD、DDD（作为方法时）、ATAM、TOGAF-ADM	数据流体系风格、调用/返回体系风格、虚拟机体系风格等

 

为了更好的理解上述两个概念，

我们可以分成两个视角看架构过程：

1、架构形态金字塔（从抽象约束到具体模板）

• 顶层：架构风格：最高层抽象约束，定义组件、连接器、交互拓扑，不绑定业务。如分层、管道‑过滤器、事件驱动、客户端‑服务器。
• 中层：架构模式：组合一种或多种架构风格，面向一类业务 / 技术问题给出可复用的完整架构模板。如微服务架构模式，MVC架构模式。

2、独立的设计过程维度（用来产出上面的架构）

     架构设计方法：一套步骤和思考框架，用来分析质量属性、业务域，选择合适的架构风格，推导落地成架构模式。例如 ADD 方法、DDD 领域驱动设计、结构化设计方法（SD）、面向对象设计（OOD）、ATAM 架构评估。