四层架构更经典：三层是四层的特例

“UI层+SI层+PD层+DM层”四层架构比[[三层架构的职责划分与调用关系]]更经典。UI层（用户界面层）负责封装与用户的双向交互、屏蔽具体交互方式；SI层（系统交互层）负责封装硬件的具体交互方式以及外部系统的交互；PD层（问题领域层）负责问题领域或业务领域的抽象、领域功能的实现；DM层（数据管理层）负责封装各种持久化数据的具体管理方式（数据库、二进制文件、文本文档、XML文档、Flash存储结构等）。四层架构之所以更经典，是因为无论嵌入式控制系统还是复杂业务应用系统，三层架构都不够用——它缺少一个专门负责封装硬件访问、外部系统交互的层。事实上常用的三层架构，只是四层架构模式的一种具体应用：三层一是忽略了”系统交互层”（因为很多业务系统本来就不需要和硬件或外部系统直接交互），二是单独提炼出了”业务实体层”（原本PD层的一部分内容被拆分出来命名）。书中用一个网管系统的真实设计案例演示了对这四层划分的具体运用和常见误判：设计者把系统分成管理控制部分（系统内部管理和控制）、适配层（和被管节点即设备/网络/系统之间的连接，负责数据采集或控制数据下传——这正是经典的SI层，封装被网管软件管理的设备、网络、系统的具体交互方式）、核心层（功能业务实现层和数据处理中心，含多个业务功能组件）、展现层（应用实现的接口，包括各种人机界面对外接口）。书中特别指出展现层里”对外接口”这部分容易被误判归属：如果这部分逻辑负责和外部系统做双向交互（比如事件队列），就应该划归SI层；否则它其实是PD层所提供服务的一层可远程访问的二次封装，不应该笼统地归入UI层——这个纠错说明四层架构的归类判断，最终要看这部分代码”真正在和谁交互”，而不能只看它字面上叫”展现层”还是”接口”。

结构图：

flowchart TB
    subgraph 四层架构["四层架构（更经典）"]
        UI["UI层\n封装与用户的交互"]
        SI["SI层\n封装硬件/外部系统交互"]
        PD["PD层\n问题领域抽象与实现"]
        DM["DM层\n封装持久化数据管理"]
    end
    subgraph 三层架构["三层架构（四层的特殊应用）"]
        Present["展现层"]
        Business["业务层\n（含业务实体层，PD层拆出）"]
        Data["数据层"]
    end
    UI -.->|"三层忽略SI层\n（假设无硬件/外部系统交互）"| Present
    PD -.->|"拆出业务实体层"| Business
    DM -.-> Data