多涉众视角冲突与架构视图的必要性

“什么是软件架构”之所以在团队内部争论不休，一个常被忽视的原因是：不同角色其实是站在各自的工作职责上定义架构的，谁都没错，但谁说的都只是架构的一部分——程序员看到的架构是”要写哪些类、用哪些库和框架”，程序经理看到的是”模块划分和接口定义”，系统分析员看到的是”业务领域对象关系建模”，配置管理员看到的是”编译产出物的目录结构”，数据库工程师看到的是”持久化数据的结构”，部署工程师看到的是”软件到硬件的部署策略”，用户看到的是”系统被划分成的一个个功能子系统”。这些视角单独看都不完整，合在一起才勉强拼出架构的全貌，但如果不做区分地混在同一份文档里讨论，”架构师”反而会被撕扯得最痛苦——因为他必须同时对所有这些涉众负责。这个洞察直接推出了”为什么架构视图必不可少”的答案：架构视图的本质是”分而治之”，让架构师能够从不同角度分别设计、分别交流，而不是试图用一份大而全的文档同时满足所有涉众的关注点。总结下来，架构师需要同时对四类对象负责：为”上游”客户负责，满足其业务目标和约束条件；为”上游”用户负责，满足其功能需求和运行期质量属性；为”下游”开发人员负责，因为架构最终要交由开发人员实现；为”周边”管理人员负责，为他们的分工管理、进度评估提供清晰基础。