阅读 21

从三层架构迈向领域驱动设计(转载)

三层架构

file严格分层架构模式的特点是上层只能访问相邻的下层,其他层次间的调用都不允许。三层架构就是一种严格分层模式,它把职责划分为界面展示、业务逻辑、数据访问三层,还有一个业务实体,前面三层都要依赖它,所以它并不构成一个层。

三层架构的特点是一种面向过程的编程思想,特点如下:

a. 业务实体类中基本上只有属性没有方法。

b. 业务逻辑层的类基本上只有方法没有属性。

c. 将数据表结构映射为业务实体类是一个惯用做法,以至于有人将其称之为“传统”。这样的好处是只需要理解一套模型,能够通过自动化工具从数据表直接生成业务实体,还能够自然而然的通过自动化机制存储与检索业务实体。但对于复杂点的业务,这样做就是绝大部分问题的根源。

d. 当业务膨胀起来,需要划分模块的时候,我们有个常用的变形:提取一个服务层出来,用来组合模块间的交互,还为业务逻辑层提供了一个防腐层,可以把记录日志、验证权限、处理异常等职责分配给服务层。

file

由于采用了严格分层模式,用户界面层是绝对不能跨过业务逻辑层调用数据访问层的,同理服务层也是不能调用数据访问层。但是图2都有四层了。

其实三层架构还有个更准确的名字----分层贫血领域模型架构,前面名字中的领域模型指的是业务实体,贫血意思业务实体中没有或很少方法。

三层架构的反思

三层架构的最大问题在于:实际应用中人们喜欢把内存模型和数据库模型保持一致。三层架构的大部分问题都是从这里衍生出来的。

数据库模型的粒度如果很小,那么大量的表连接很快就会让数据库跑不动了。

如果数据库模型的粒度如果很大(这是大部分项目的选择),代码的质量(重用性、稳定性、扩展性)就很差。由于没有从业务的角度去仔细定义每一个对象,每个人会根据自己的需要建立各种QueryModel或ViewModel,慢慢地类会多到想哭。

还有一些三层开发人员最终患上了数据库痴迷症,他坚信程序就应该做个搬运工,其他的事情都应该交给数据库来完成,业务逻辑也应该写进存储过程里面去。

三层分层到DDD分层的转变过程

优化三层结构&重构到面向对象的设计

file

由于目前的服务层职责是非常轻的,甚至有很多空壳的调用,所以平衡一下职责,把调用数据访问层的职责从业务逻辑层提升到服务层,需要的数据通过参数传递给业务逻辑层。这样,对于那些简单到无业务逻辑的CRUD就不需要去访问业务层了,直接调用数据访问层。

结构如图3,我们看到业务逻辑与数据访问层已经没有依赖关系了。

然后我们就可以把业务逻辑与业务实体移到一块。

然后把属于业务实体的逻辑迁移到实体类中。

file

图4基本上就是图3的各个层换了名字,并且UI可以访问基础设施层。而图4与图5的区别在于,图4是基础设施依赖领域层,图5是领域层依赖基础设施层。

file

用户界面层:

原版----负责向用户展现信息以及解释用户命令。

补充---- MVC中V和C都属于UI层,V展现信息,C解析用户命令。UI像地图一样把各个控制器关联了起来。

应用层

原版----很薄的一层,用来协调应用的活动。它不包含业务逻辑。它不保留业务对象的状态,但它保有应用任务的进度状态。

补充----协调应用的活动这句话太抽象了,我充实一下它:从数据访问中获取领域对象,调用领域对象的方法完成任务,然后再调用数据访问代码把领域对象的改变持久化。事务、权限检查、记录日志、处理异常的职责也归它管。这点和前面三层的服务层的职责其实是一样的。

领域层

原版----本层包含关于领域的信息。这是业务软件的核心所在。在这里保留业务对象的状态,对业务对象和它们状态的持久化被委托给了基础设施层。

补充----业务对象的持久化工作我们已经提升到应用层了,一般情况下,这层最好不要涉及资源库的调用,但是并不绝对。资源库的抽象要么在领域层中,要么提升到了“应用程序框架”,领域层是不会依赖基础设施的。

基础设施层

原版----本层作为其他层的支撑库存在。它提供了层间的通信,实现对业务对象的持久化,包含对用户界面层的支撑库等作用。

对比三层分层与DDD分层

a. UI层技术基本一样,一些比较智能的绑定可能无法进行了。

b. 服务层基本一样。

d. 业务实体+业务逻辑 = 领域层

e. 如果三层架构不采用业务实体与数据表一致的做法,这层也是一样。由于内存结构与数据表结构之间存在阻抗失配,存取领域对象没那么简单。

参考资料

《领域驱动设计精简版》

评论