软件架构问题的独特起源：不是为解决危机而生

高级语言、结构化编程、面向对象这些此前的软件方法论，无一例外都是为了应对一次全行业共同经历的”危机”而诞生的——某种普遍存在的痛点先爆发成行业性问题，方法论再作为解药出现。软件架构的诞生路径完全不同：它既不是为了解决某种新的软件危机，也不是整个行业普遍都在经历相同的困境。卡内基·梅隆大学的玛丽·肖和戴维·加兰在1994年那篇奠基性文章里给出的解释是——当系统由许多部分组成时，”整个系统该怎么组织”这件事本身，会催生出一整套全新的设计问题，而这类问题不会随着系统规模变大自然消失，只会变得更突出。这也解释了为什么”软件架构”最早是在Rational、Microsoft这类大公司内部开始流行的：只有开发着足够大规模系统的团队，才会真切地撞上系统规模庞大导致的内部耦合严重、开发效率低下，系统改一处就牵动全身、后续修改扩展困难，逻辑复杂到出问题后很难排查定位这几类具体痛点，而这些痛点在小规模系统里根本不会显现出来、也就没有动力去专门应对。这提示一个判断依据：架构问题不是靠某种技术缺陷触发的，而是靠系统规模本身触发的——一个系统要不要认真考虑”架构”，第一个该问的问题不是”我们用的技术栈够不够先进”，而是”我们的系统规模是否已经大到组织方式本身开始成为独立的设计难题”。