《软件架构设计》学习笔记--7--6大步骤3：确定关键需求

成为一名合格的架构师是每个开发者的梦想。成为合格架构师的难点在于预见系统问题的思考方式。——曾登高，CSDN技术总监

本篇记录6大步骤中的第三步：确定关键需求。包括如下内容：

• 什么决定了架构？
• 如何确定关键需求？
• 实际应用

1、什么决定了架构

关于“什么决定了架构”，业界存在三种观点：

• 用力驱动论
• 质量决定论
• 经验决定论

在本书《软件架构设计》的8.1章节，作者一一给予了辩论。最后，作者提出了自己的观点：关键需求决定架构，其余需求验证架构。
这有点《矛盾论》中“矛盾辩证关系的原理”一样，主要矛盾对事物发展起决定作用。
作者总结了一张表，用以阐述不同需求(功能、质量、约束)对架构如何产生影响。

2、如何确定关键需求

有了方向之后，那么问题来了，如何确定关键需求呢？
确定关键需求，架构师具体要做什么呢？

• 一方面，不同质量属性之间往往具有相互制约性，于是我们自然应该权衡哪一部分质量属性是架构设计的重点目标。
• 另一方面，功能需求数量众多，应该控制架构设计时需要详细分析的功能（或用例）的个数。

2.1确定关键质量

质量属性包括性能、安全性、持续可用性、互操作性、等不一而足。通过下表，作者表达了各种质量属性的关系及影响。

2.2确定关键功能

可通过如下4条启发规则，确定关键功能子集：

• 核心功能
• 必做功能
• 高风险功能
• 独特功能（覆盖了上述3类功能没有设计的职责）

只要能较好地覆盖组成架构的不同职责模块，并体现职责模块之间协作关系的特点，那么“关键功能子集”的价值也就体现出来了。
为什么架构师的经验很重要呢，确定“关键需求”靠的就是经验，目的是用有限的时间针对关键需求把设计做到位、并减小需求变更对架构设计的影响。

3、实际应用

本书中，作者围绕PM Suite（项目管理系统）贯穿案例，以此说明小系统和大系统的架构设计之所以不同，归根溯源是由于架构要支撑的“关键需求”不同造成的。整个架构设计过程中的“确定关键需求”这一环节，可谓小系统和大系统架构设计的分水岭，架构设计走向从此大不同。
最后，作者得出心得：拿来主义虽好，但要合适才行。

架构设计只有合适，没有最好。
无视条件差异照抄架构，危险。