概念架构不等于理想化架构

概念架构设计的输入是”关键需求进，概念架构出”——针对关键功能运用鲁棒图设计，针对关键质量运用目标-场景-决策表设计，两者缺一不可。但实际工作中，单纯采用功能需求驱动的方式看似高效，实际却犯了一个常见错误：把”概念架构”等同于”理想化架构”。所谓理想化架构，就是一门心思只考虑功能需求、完全不考虑非功能需求设计出来的架构——比如总是忽略硬件限制、带宽限制、专利限制、使用环境、网络攻击、系统整合、平台兼容等现实存在的各种约束性需求。这种设计方式的危险在于：它在纸面上、在演示阶段可能看起来运转良好，因为忽略约束意味着少了很多”麻烦事”，但这样设计出来的概念架构后期几乎必然要面临大改——一旦真实的硬件条件、带宽限制、安全攻击场景、系统集成需求浮出水面，理想化架构里那些从未被考虑过的约束会一次性反扑，而这时候往往已经是项目后期，返工成本远高于在概念架构阶段就纳入约束考量的成本。这个误区的根源可以追溯到[[质量决定论的局限]]和[[用例驱动论的局限]]所批判的同一类思维——把需求简化成单一维度（这里是”只看功能”），而概念架构设计的正确姿态始终是”左手功能、右手质量”两手抓，两手都要硬，任何一手偏废都会导致概念架构失去它本该承担的”直指目标”的作用。