微信公众号搜"智元新知"关注
微信扫一扫可直接关注哦!

DDD领域模型和持久模型的实施方式不定期更新ing

在领域驱动设计中,领域模型和持久模型往往存在阻抗失配,两个模型往往不能达到一致,我们需要用两个类来分别实现。

领域模型更倾向于业务场景;

领域模型不包含任何框架技术,只有标准库依赖和一些第三方工具类的依赖;

领域模型不需要为属性实现set方法,只需要实现业务逻辑的方法和需要属性的get方法,保持最

小知识原则;

领域模型需要自己实现业务规则的校验方法,比如一台家用轿车有4个轮胎、1个引擎等;

领域模型在领域内成熟之后会趋向于稳定。

持久模型更倾向于数据库

持久化模型会依赖于实现技术,比如jpa实现就会包含jpa的注解等;

持久模型是为ORM或其他持久化技术服务的,一般都需要为每个属性创建get/set方法,是一个贫血模型;

持久模型常和一些验证框架一起使用保证数据库数据的合法性@NotNull,@StringLength等等;

持久模型随着技术的改进,比如加缓存,分库分表,更换持久化实现,会出现不同形式的更改;

领域仓储repository有责任为领域模型隐藏持久化的实现技术,

它的接口只返回领域模型(更确切的说应该是返回聚合根),

仓储的实现中有必要实现 持久模型(下面的UserEntity)->领域模型(下面的User) 的映射转换,

也就是说 持久模型UserEntity 就应该暴露到下面这一层映射代码位置,仓储的实现是处于ddd中的基础设施层,不能泄漏到更上层的领域层,

@Repository
public class UserRepositoryImpl implement UserRepository
{
    @Autowired
    private UserEntityRepository userEntityRepository;


    public User getById(int userId)
    {
        UserEntity persistanceModel = userEntityRepository.GetById(userId);
        User domainModel = new User (
            persistanceModel.id,persistanceModel.username);

        return domainModel;
    }
}

原文地址:https://www.jb51.cc/javaschema/283405.html

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。

相关推荐