层次结构不等于平台化，判断标准是面向构成还是面向方向

一个常见的误解是把”分层”本身当成”平台化”，比如认为搭了一个三层架构（表现层/业务层/数据层）就等于做出了[[平台与框架看不见的两种极致|大到看不见]]的平台。层次结构只是实现平台化的一种表现方法，而不是平台化本身——判断某个层次结构是否真正具有平台特性，要看它是”基于系统构成”还是”面向系统方向”来划分层次：基于系统构成的分层只是把系统内部已有的技术职责（如”处理请求”和”存取数据”）切成几块，这几块之间即使能各自替换，也不构成真正的平台，因为它反映的是系统当下的技术构造方式，而非某种可以长期不变、脱离具体实现细节的抽象；面向系统方向的分层则要考虑客户战略——书中区分了用户方客户与开发方客户两类客户战略，一个方向服务于最终使用系统的业务用户，另一个方向服务于在此基础上继续开发的技术团队。以J2EE为例：它统一了框架层与服务层的划分，解决了功能渐增、组件复用、跨环境部署这三类需求，但这个统一本质上仍然是”框架”方向而非”平台”方向——因为它站在的是计算机系统的视角（如何组织代码与运行环境）而非业务视角（这套系统对业务战略意味着什么），所以J2EE即便被称作”平台”，在这里的判定标准下仍然只是一种精致的框架化方案。可迁移启发：审视一个宣称”平台化”的系统分层设计，先问它划分层次的依据是什么——如果依据是”这几个模块技术上各管一段”，那只是分层；只有当分层背后能追溯到对客户战略、业务方向的响应，才谈得上真正的平台化。