三层架构
严格分层架构模式的特点是上层只能访问相邻的下层,其他层次间的调用都不允许。三层架构就是一种严格分层模式,它把职责划分为界面展示、业务逻辑、数据访问三层,还有一个业务实体,前面三层都要依赖它,所以它并不构成一个层。
三层架构的特点是一种面向过程的编程思想,特点如下:
a. 业务实体类中基本上只有属性没有方法。
b. 业务逻辑层的类基本上只有方法没有属性。
c. 将数据表结构映射为业务实体类是一个惯用做法,以至于有人将其称之为“传统”。这样的好处是只需要理解一套模型,能够通过自动化工具从数据表直接生成业务实体,还能够自然而然的通过自动化机制存储与检索业务实体。但对于复杂点的业务,这样做就是绝大部分问题的根源。
d. 当业务膨胀起来,需要划分模块的时候,我们有个常用的变形:提取一个服务层出来,用来组合模块间的交互,还为业务逻辑层提供了一个防腐层,可以把记录日志、验证权限、处理异常等职责分配给服务层。
由于采用了严格分层模式,用户界面层是绝对不能跨过业务逻辑层调用数据访问层的,同理服务层也是不能调用数据访问层。但是图 2 都有四层了。
其实三层架构还有个更准确的名字 —- 分层贫血领域模型架构,前面名字中的领域模型指的是业务实体,贫血意思业务实体中没有或很少方法。
三层架构的反思
三层架构的最大问题在于:实际应用中人们喜欢把内存模型和数据库模型保持一致。三层架构的大部分问题都是从这里衍生出来的。
数据库模型的粒度如果很小,那么大量的表连接很快就会让数据库跑不动了。
如果数据库模型的粒度如果很大(这是大部分项目的选择),代码的质量(重用性、稳定性、扩展性)就很差。由于没有从业务的角度去仔细定义每一个对象,每个人会根据自己的需要建立各种 QueryModel 或 ViewModel,慢慢地类会多到想哭。
还有一些三层开发人员最终患上了数据库痴迷症,他坚信程序就应该做个搬运工,其他的事情都应该交给数据库来完成,业务逻辑也应该写进存储过程里面去。
三层分层到 DDD 分层的转变过程
优化三层结构 & 重构到面向对象的设计
由于目前的服务层职责是非常轻的,甚至有很多空壳的调用,所以平衡一下职责,把调用数据访问层的职责从业务逻辑层提升到服务层,需要的数据通过参数传递给业务逻辑层。这样,对于那些简单到无业务逻辑的 CRUD 就不需要去访问业务层了,直接调用数据访问层。
结构如图 3,我们看到业务逻辑与数据访问层已经没有依赖关系了。
然后我们就可以把业务逻辑与业务实体移到一块。
然后把属于业务实体的逻辑迁移到实体类中。
图 4 基本上就是图 3 的各个层换了名字,并且 UI 可以访问基础设施层。而图 4 与图 5 的区别在于,图 4 是基础设施依赖领域层,图 5 是领域层依赖基础设施层。
用户界面层:
原版 —- 负责向用户展现信息以及解释用户命令。
补充 —- MVC 中 V 和 C 都属于 UI 层,V 展现信息,C 解析用户命令。UI 像地图一样把各个控制器关联了起来。
应用层
原版 —- 很薄的一层,用来协调应用的活动。它不包含业务逻辑。它不保留业务对象的状态,但它保有应用任务的进度状态。
补充 —- 协调应用的活动这句话太抽象了,我充实一下它:从数据访问中获取领域对象,调用领域对象的方法完成任务,然后再调用数据访问代码把领域对象的改变持久化。事务、权限检查、记录日志、处理异常的职责也归它管。这点和前面三层的服务层的职责其实是一样的。
领域层
原版 —- 本层包含关于领域的信息。这是业务软件的核心所在。在这里保留业务对象的状态,对业务对象和它们状态的持久化被委托给了基础设施层。
补充 —- 业务对象的持久化工作我们已经提升到应用层了,一般情况下,这层最好不要涉及资源库的调用,但是并不绝对。资源库的抽象要么在领域层中,要么提升到了“应用程序框架”,领域层是不会依赖基础设施的。
基础设施层
原版 —- 本层作为其他层的支撑库存在。它提供了层间的通信,实现对业务对象的持久化,包含对用户界面层的支撑库等作用。
对比三层分层与 DDD 分层
a. UI 层技术基本一样,一些比较智能的绑定可能无法进行了。
b. 服务层基本一样。
d. 业务实体 + 业务逻辑 = 领域层
e. 如果三层架构不采用业务实体与数据表一致的做法,这层也是一样。由于内存结构与数据表结构之间存在阻抗失配,存取领域对象没那么简单。
参考资料
《领域驱动设计精简版》