软件架构诞生的历史必然性：模块、对象、组件的拆分粒度递进

“模块”“对象”“组件”这三个在不同年代先后诞生的概念，本质上做的是同一件事——把规模已经超出人脑单次能掌握范围的软件系统拆解成更小的单元，差别只在于拆分的粒度和层次随着软件复杂度的增长而不断变粗、变高。20世纪60年代第一次软件危机催生了结构化编程，创造出”模块”概念，用来把一段复杂的执行逻辑拆成一个个自顶向下、逐步细化的功能单元；20世纪80年代第二次软件危机催生了面向对象编程，创造出”对象”概念，把数据和行为封装到一起、按业务实体来组织代码，拆分的层次比单纯的逻辑模块更高一级；20世纪90年代，随着系统规模进一步扩大到即使用面向对象也难以驾驭整体组织方式的程度，”软件架构”开始流行，创造出”组件”概念，把系统拆成可以独立部署、独立复用的物理单元，拆分层次又比对象更高一级。这条”模块→对象→组件”的演进链路揭示了一个可迁移的规律：当既有的拆分粒度已经不足以驾驭系统的规模和复杂度时，软件工程领域的应对方式历来不是发明全新的解决思路，而是把拆分的粒度和层次继续往上提一级——这也是为什么《人月神话》里1964年开发的IBM 360系统会陷入那样的困境：当时结构化编程都还没被提出来，可用的拆分工具本身就配不上System/360那样的系统规模。

结构图：

flowchart LR
  A["模块<br/>1960s 第一次软件危机<br/>结构化编程<br/>拆分执行逻辑"] --> B["对象<br/>1980s 第二次软件危机<br/>面向对象编程<br/>拆分数据+行为的业务实体"]
  B --> C["组件<br/>1990s 系统规模持续增长<br/>软件架构<br/>拆分可独立部署复用的物理单元"]
  A -.拆分粒度越来越粗，拆分层次越来越高.-> C