架构设计如何满足系统品质与促成利益相关者共识

软件的功能性可以通过架构里各元素之间的交互来直接支撑，但性能、安全性、可维护性这类品质属性不一样——它们不会被局限在某一个单独的架构元素里，而是渗透在整个架构体系当中，缺少一个统一的架构设计视图就根本无从实现。比如要满足性能要求，必须同时考虑架构中每一个组件自身的实现耗时，以及组件之间通信所花费的时间，两者缺一不可；要满足安全性要求，需要审视两个组件之间”自然”的通信路径，并在真正需要的地方专门引入安全性提示组件——这些考量涉及的都是组件自身和组件之间关系的整体视角，而不是某个局部代码片段能单独解决的问题。这解释了为什么品质属性的保障必须从架构层面介入：架构设计带来的一个直接好处，就是可以在项目开发周期的早期阶段就对这些品质属性做评估，而不必等到系统建成之后才发现品质缺陷、再回头返工。除了品质保障，架构设计还有一个容易被忽视的社会性作用：它能让不同的利益相关者（客户、产品、开发、运维等）就系统方案达成一致目标，因为架构设计过程本身提供了一个可以摆到台面上辩论系统解决方案的渠道。这个作用能否兑现，关键在于架构是否被”有效传达”——一个被清楚传达和理解的架构，能让各方就决议和权衡反复讨论、最终形成共识；反之，如果架构本身没有被有效地传达给相关各方，这种辩论根本不会发生，而缺乏这种辩论过程产生出来的架构结果，往往品质也偏低——这说明架构文档化和沟通本身，不是架构设计之外的附加工作，而是架构能否真正发挥协调作用的必要前提。