功能、质量、约束影响架构的三种不同原理

“需求决定架构”这句话之所以经常沦为空洞口号，是因为大多数人不知道功能、质量、约束这三类需求各自是”如何”影响架构设计的——精通这三种不同原理，正是从需求向设计转化的”密码”，少了这一环，”重视需求”就只是嘴上说说，需求和设计会变成”两层皮”，设计沦为拍脑袋。功能影响架构的原理是职责协作链：任何一项功能都由一条特定的职责协作链完成，软件系统支持每个具体功能时，都涉及不同”部分”之间的相互配合，控制权在这些部分之间来回传递，形成协作链；反过来设计架构时，就是通过为功能规划职责协作链来发现职责，再把职责分配到子系统等软件单元中，进而定义接口、确定协作方式。质量影响架构的原理是”完善驱动力”、也就是进一步质疑：不考虑质量的系统走不出实验室，但抛开功能单靠质量要求是不可能设计出架构的（书中用一个反问说明：不告诉业务领域和功能要求，仅凭”要高性能”这个条件，没人能评审出一个具体架构）——实际设计过程是把质量当成一种评价手段，针对已经存在的架构设计中间成果，基于当前设计进一步质疑、细化、调整、甚至推倒重来，例如”页面缓存”这个设计如果只考虑功能永远不会被引入，它正是质疑性能后调整设计的产物。约束影响架构的原理是”设计并不自由”：约束性需求潜藏大量风险因素，有经验的架构师会主动分析约束的具体影响方式，而约束影响架构至少有三种不同的具体转化方式——直接制约设计决策的约束（如”系统运行于UNIX平台之上”，架构师直接遵守）、转化为功能需求的约束（如”必须严格执行人民银行统一利率”这条约束，分析后会引出”必须提供调整利率设置的功能”这条功能需求）、转化为质量属性需求的约束（如”各储蓄所柜员计算机水平普遍不高”这条约束，会推出系统必须具备很高的易用性和鲁棒性这两条质量要求）。

结构图：

flowchart LR
    F["功能需求"] -->|"规划职责协作链\n发现职责→分配单元→定义接口"| FA["架构决策"]
    Q["质量需求"] -->|"对已有设计成果\n进一步质疑/细化/调整"| FA
    C1["约束（直接类）"] -->|"直接遵守"| FA
    C2["约束（隐含功能类）"] -->|"转化为功能需求"| F
    C3["约束（隐含质量类）"] -->|"转化为质量属性需求"| Q