五视图方法背后"组件+交互"的统一思想

实际中的架构设计工作范围极其广泛——子系统划分、接口定义、进程线程设计、服务器选型、Layer（逻辑层）还是Tier（物理层）的取舍、源码目录结构、数据库Schema还是文件格式……单单”我要把系统切成啥”这一个问题，就不是一道单选题：和客户沟通时系统是垂直功能子系统，写程序时系统是程序包，运行时系统是进程线程。面对这种”思维混乱”，5视图方法给出了系统性的分类：Layer作为大粒度”职责划分”单位属于逻辑架构视图，Tier则属于物理架构视图，关注硬件部署——这样架构新手常常混淆的Layer/Tier之别，一下子就有了清晰的归属。嵌入式系统的例子同样如此：为支持并发的中断服务程序，属于运行架构视图的”控制流的技术选型”；基于文件（而非数据库表）、最终写入Flash（而非硬盘）的持久化方式，属于数据架构视图。看似复杂的5视图方法，其”思想”其实并不复杂——因为每个视图都是从特定角度规划系统的”分割与交互”，都是[[组件加交互抽象具体设计]]这个架构核心定义在不同层次上的具体体现：逻辑架构=职责单元+协作关系；开发架构=程序单元（源程序、目标程序、程序库Library等）+编译依赖关系；运行架构=控制流+同步关系；物理架构=物理节点+拓扑连接关系；数据架构=数据单元+数据关系。提炼出这层”繁中之简”之后，5视图方法的价值就显现出来了：它把众多技术关注点错落有致地划分成不同的”群落”，群落内高聚合、群落间松耦合，这正是系统思考的力量所在——不是死记硬背五个视图名字，而是理解每个视图本质上都在回答”这个层次上，组件是什么、它们如何交互”这同一个问题。