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

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可能运行异常。无疑增大了后期改动的风险。毕竟项目后期更改是必须的。所以在数据准确性要求十分严格的时候，不建议使用领域模型。