DDD领域模型和充血对象在实际项目中的问题

/ 架构 / 0 条评论 / 700 浏览

DDD领域模型

DDD领域模型是一个基于业务角度创建的一种逻辑模型、是业务即设计的思想。

具体参考:http://blog.lianglianglee.com/article/domain-driven-design

充血对象

充血对象是把一部分业务放到实体上,也就是业务判断放到实体中完成,好处是业务判断集中。业务出现更改,只需要更改实体即可。

具体参考:http://blog.lianglianglee.com/article/ddd-model

技术

由于充血对象在实际编码过程中,依赖于实体托管功能,所以在技术上,ORM基本使用Hibernate,Jpa这两种多,依赖于托管对象和事务,让整个模型和充血对象能够实现。

主要依赖于:实体托管,实体关联功能。

实现

在实体中设置OneToMany 等关联关系,就可以省略聚合根内部实体的ORM操作,在Jpa中也就是JpaRepository。角色实体设计如下:

依赖于这种设计,在事务中,直接操作role对象的roleDetails,在事务结束后,Jpa会自动提交托管的role对象。

这样就实现了充血对象和领域模型的设计。

在简单的业务中,该方式十分方便,操作对象和取出对象时,只需要操作聚合根即可。

问题

上述说了,在简业务中,会十分方便,但是在一些数据校验场景中需要处理的时候,就会有问题。

简单的场景举例:

需要删除某个权限的时候,需要删除所有角色中的该权限。所以需要操作role_detail表,这个时候,由于没有JpaRepository ,无法直接操作表,又不能遍历role,只能写SQL通过EntityManage操作这张表。

这是一个很严重的问题,在项目中,这种场景会经常出现,所以需要频繁的写SQL,操作内部实体十分不方便。

可以发现,在所有的内部类校验中,都麻烦,由于SQL问题,更导致后期表结构变化,SQL可能运行异常。无疑增大了后期改动的风险。毕竟项目后期更改是必须的。所以在数据准确性要求十分严格的时候,不建议使用领域模型。