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

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

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

领域模型不需要为属性实现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;
    }
}