五种分层方式的比较与中介层可选原则

本书采用的表现层/领域层/数据源层三层模型并不是唯一的分层方式，其他架构教材各有取舍。Brown模型在三层基础上插入两个中介层，共五层：表现层、控制层/中介层（表现层与领域层之间，对应本书的应用控制器）、领域层、数据映射层（领域层与数据源层之间，对应本书的数据映射器）、数据源层。J2EE Core Patterns方案分五层：客户层、表现层、业务层、集成层、资源层——它的独特之处是把”表现层”拆成了客户端部分（客户层）和服务器端部分（表现层），业务层与集成层大致对应、资源层则是集成层要连接的外部服务。Microsoft DNA架构定义表现层、业务层、数据访问层三层，结构上和本书三层能对上号，但关键区别在于数据传递方式：所有层都直接操作数据访问层通过SQL产生的记录集，这个记录集实质上充当了各层之间的数据传输对象，代价是业务层和表现层都被迫要了解数据库结构，好处是表现层可以直接用一些对数据敏感的GUI控件操作被业务层修改过的记录集（这种架构下领域层常组织成表模块、数据源层用表数据入口）。Marinescu方案用五层，把领域层拆成了领域模型加一层服务层——本质是把面向用例的工作流逻辑从纯粹的领域逻辑里剥离出来，是否值得这样拆分存在争议，作者个人认为偶尔有用、大多数情况没必要。Nilsson模型层次更复杂，因为大量依赖存储过程、鼓励把领域逻辑塞进存储过程以求性能，作者本人并不认同这种做法（会增加维护开销），但承认这是一种（用得不多的）优化技巧；Nilsson也和Marinescu一样单独设了应用层和领域层，并同样认为小型系统可以不设领域层——这一点上两人和作者的立场一致：领域模型对小型系统意义不大。作者本人的方法论是：先从三个基本层出发，只有当它们真的变得过于复杂时，才考虑引入应用控制器、数据映射器这类中介层来分担压力——中介层始终是可选的额外方案，不是起手就该有的标配。

结构图：

flowchart TB
  A["本书三层:表现/领域/数据源"]
  B["Brown模型五层<br/>+控制层(应用控制器)+数据映射层"]
  C["J2EE Core Patterns五层<br/>客户/表现/业务/集成/资源"]
  D["Microsoft DNA三层<br/>记录集充当跨层DTO，但各层需懂数据库"]
  E["Marinescu五层<br/>领域层拆成领域模型+服务层"]
  F["Nilsson模型<br/>大量依赖存储过程装领域逻辑"]
  A -.->|"复杂度上升才加中介层"| B