解密DDD:高内聚对象组的维护之道

开发 前端
JPA 与 DDD 的==聚合写== 是绝配,但在 “读” 场景 往往会引发各种性能问题。这也是很多公司弃用 JPA 而选择 MyBatis 的主要原因,就其本质并不是框架的错,而是将框架用在了错误的场景。

1. 初始 Repository

在 DDD 中,Repository 是一个非常重要的概念,它是领域层的一个组件,用来管理聚合根的生命周期和持久化。

1.1. 核心为状态管理

DDD 是由领域对象承载业务逻辑,所有的业务操作均在模型对象上完成,同一聚合上不同的业务操作构成了聚合的生命周期。

我们以订单为例,如下图所示:

  1. 首先,用户操作下单,使用提交数据为其创建一个 Order 对象,版本 V1;
  2. 随后,用户进行改地址操作,调用 Order 对象的 modifyAddress 方法,Order 从原来的 V1 变成 V2;
  3. 用户完成支付后,调用 Order 对象的 paySuccess 方法,Order 从 V2 变成 V3;

整个流程很好的体现了 Order 聚合根的生命周期。

1.2. 为什么需要 Repository?

假设,有一台非常牛逼的计算机,计算资源无限、内存大小无限、永不掉电、永不宕机,那最简单高效的方式便是将模型对象全部放在内存中。

但,现实不存在这样的机器,我们不得不将内存对象写入磁盘,下次使用时,在将其从磁盘读入到内存。

整体结构如下图所示:

和上图相比,具有如下特点:

  1. 业务操作没变,仍旧依次完成 下单、改地址、支付等操作
  2. 引入持久化存储(MySQL),可以将 Order 对象存储于关系数据库
  3. 配合 Order 的生命周期,操作中增加 save、load 和 update 等操作
  1. 用户下单创建 Order 对象,通过 save 方法将 Order 对象持久化到 DB
  2. 接收到业务操作,需执行load,从 DB 加载数据到内存 并对 Order 对象的状态进行恢复
  3. 在业务操作完成后,需执行update,将 Order 对象的最新状态同步的 DB

相对全内存版本确实增加了不小的复杂性,为了更好的对这些复杂性进行管理,引入 Repository 模式。

在领域驱动设计(DDD)中,Repository 是一种设计模式,它是用来存储领域对象的容器。它提供了一种统一的方式来查询和存储领域对象。Repository提供了对底层数据存储的抽象,允许应用程序在没有直接与数据存储技术交互的情况下访问数据,同时该抽象允许在不修改应用程序代码的情况下更改数据存储技术。

【注】在 DDD 中,Repository 并不是一个 DAO,它的职责比 DAO 要多得多,它管理的是整个聚合根,而不是单个实体对象。同时,Repository 还需要提供一些查询接口,用来查询聚合根的状态。

2. 什么是好的 Repository?

Repository 主要用于完成对聚合根生命周期的管理,所以必须提供三组操作:

  1. 保存。将聚合根同步到底层存储进行持久化处理;
  2. 查询。根据 ID 或属性从底层存储引擎中读取数据并恢复为内存对象,也就是聚合根对象;
  3. 更新。聚合对象发生变更后,可以将新的状态同步到存储引擎,以便完成数据更新;

有人会说,这和 DAO 没啥区别吧!!!

DAO 是单表单实体操作,Repository 操作的是整个聚合甚至包括继承关系,这就是最大的区别。也就是Repository 必须能够:

  1. 维护一个完整的对象组,也就是必须能处理对象的组合关系;
  2. 维护一个完整的继承体系,也就是必须能够处理对象继承关系;

既支持组合又支持继承,DAO 就没办法更好的承载了。
那就完了吗?并没有!!!

聚合根是一个对象组,包含各种关系,并不是每个业务操作都需要聚合根内的所有实体。
举个例子,在电商订单聚合根内,包括:

  1. 订单(Order)。记录用户的一次生单,主要保存用户、支付金额、订单状态等;
  2. 订单项(OrderItem)。购买的单个商品,主要保存商品单价、售价、应付金额等;
  3. 支付记录(Pay)。用户的支付信息,包括支付渠道、支付金额、支付时间等;
  4. 收货地址(Address)。用户的收货地址;

在改价流程里,需要修改 Order、OrderItem、Pay 三组实体。
在更新地址流程里,仅需要修改 Address 和 Order 两组实体。

为了满足不同的业务场景,Repository 需要具备两个高级特性:

  1. 延迟加载。只有在第一次访问关联实体时才对其进行加载,避免过早加载但实际上并没有使用所造成资源浪费问题;
  2. 按需更新。不管加载了多少组实体,在保存时仅对发生变更的实体进行更新,减少对底层存储引擎的操作次数,从而提升性能;

总体来说,能够具备以下特性的 Repository 才是好的 Repository:

  1. 支持组合关系
  2. 支持继承关系
  3. 支持延迟加载
  4. 支持按需更新

3. JPA 实例

综合调研各类 ORM 框架,只有 JPA 具备上述特性,而且和 DDD 是绝配。

3.1. 组合关系

组合是一种面向对象编程的重要概念,指一个类的对象可以将其他类的对象作为自己的组成部分。组合在DDD中使用场景最为广泛,这也是聚合的主要工作方式。也就是将一组对象保存到存储引擎,然后在从存储引擎中获取完整的对象组。

从数据视角,组合关系存在两个维度:

  1. 数量维度。指关联关系两端对象的数量,包括
  1. 一对一:一个实体对象只能关联到另一个实体对象,例如 公司 和 营业执照,一个公司只会有一个营业执照;
  2. 一对多:一个实体对象可以关联到多个实体对象,例如 订单 和 订单项,一个订单关联多个订单项;
  3. 多对一:多个实体对象可以关联到同一个实体对象,例如 订单项 和 订单,一个订单项只属于一个订单;
  4. 多对多:多个实体对象可以互相关联,例如 社团 和 学生,一个社团包含多个学生,一个学生也可以参加多个社团;
  1. 方向维度。指对象的引用关系
  2. 单向关联,只能从一端访问另一端,比如 订单存在订单项的引用,订单项没有到订单的引用;
  3. 双向关联,可以互相访问,订单存在订单项的引用,订单项也有到订单的引用;

两者组合,情况更加复杂,会产生:

  1. 单向多对一
  2. 双向多对一
  3. 单向一对多
  4. 双向一对多
  5. 单向一对一
  6. 双向一对一

聚合根是一组对象访问的入口,聚合内的所有操作都必须通过聚合根进行,所以,聚合根于其他实体的关系只能是 一对多 和 一对一;同时,所有的业务操作都是从聚合根发起,通过聚合根能关联到内部实体即可,因此也不存在双向。综上所述,DDD 对组合进行了大量简化,实际工作中主要涉及:

  1. 单向一对一
  2. 单向一对多
3.1.1. 单向一对一

通过外键的方式实现单向一对一关系,需要在主表中添加一个指向另一个表的外键,通过外键信息获取关联数据。

实体如下:

// 聚合根实现
@Entity
@Table(name = "order_info")
public class Order{
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    // 增加 @OneToOne 注解
    @OneToOne(cascade = CascadeType.ALL, fetch = FetchType.EAGER)
    private Pay pay;

    // 增加 @OneToOne 注解
    @OneToOne(cascade = CascadeType.ALL, fetch = FetchType.EAGER)
    private Address address;

    // 忽略其他属性
}


// Pay 实体实现
@Entity
@Table(name = "pay_info")
public class Pay {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    // 忽略其他属性
}


// Address 实现
@Entity
@Table(name = "address")
public class Address {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    // 忽略其他属性
}

插入记录后,order_Infor 表数据如下

其中:

  1. address_id 存储的是 Address 实体的主键;
  2. pay_id 存储的事 Pay 实体的主键;
    其中,插入数据的sql如下:
    Hibernate: insert into address (detail) values (?)
    Hibernate: insert into pay_info (order_id, price) values (?, ?)
    Hibernate: insert into order_info (address_id, pay_id, status, total_price, total_selling_price, user_id) values (?, ?, ?, ?, ?, ?)

可见,执行时先插入 address 和 pay 获取主键后,在插入到 order_info 表,从而维护外键的有效性。

3.1.2. 单向一对多

实体定义如下:

// 聚合根实体
@Entity
@Table(name = "order_info")
public class Order{
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    // 添加 @OneToMany 注解
    @OneToMany(cascade = CascadeType.ALL, fetch = FetchType.EAGER)
    // 指定多端的关联列(如果不指定,会使用第三张表来保存关系
    @JoinColumn(name = "order_id")
    private List<OrderItem> orderItems = new ArrayList<>();
    // 忽略其他属性    
}

// OrderItem 实现
@Entity
@Table(name = "order_item")
public class OrderItem {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    // 忽略其他属性
}

插入记录后,表数据如下:

order 表数据:

order+item表数据:

其中 order_item 表中的 order_id 指向 order_info 表的主键。

3.2. 继承关系

继承是面向对象编程的核心特性,但这一特性确与数据库的关系模型产生巨大阻抗。

JPA 中提供了三种继承模型,包括:

  1. 单表继承策略(SINGLE_TABLE)。父类实体和子类实体共用一张数据库表,在表中通过一列辨别字段来区别不同类别的实体;
  2. Joined 策略(JOINED)。父类和子类分别对应一张表,父类对应的表中只有父类自己的字段,子类对应的表中中有自己的字段和父类的主键字段,两者间通过 Join 方式来处理关联;
  3. 每个实体一个表策略(TABLE_PER_CLASS)。每个实体对应一个表,会生成多张表,父类对应的表只有自己的字段。子类对应的表中除了有自己特有的字段外,也有父类所有的字段。

为了更好的对比各种策略,我们以一个业务场景为案例进行分析。

在优惠计算过程中,需要根据不同的配置策略对当前用户进行验证,以判断用户是否能够享受优惠,常见的验证策略有:

  1. 只有特定用户才能享受。
  2. 只有男士或女士才能享受。
  3. 只有VIP特定等级才能享受。
  4. 未来还有很多

为了保障系统有良好的扩展性,引入策略模式,整体设计如下:

那接下来便是将这些实现类存储到数据库,然后在方便的查询出来。

3.2.1. 单表继承

单表继承非常简单,也最为实用,数据库表只有一张,通过一列辨别字段来区别不同类别的实体。

它的使用涉及几个关键注解:

  1. @Inheritance(strategy = InheritanceType.SINGLE_TABLE),添加在父类实体,用于说明当前使用的是 单表策略;
  2. @DiscriminatorColumn(name="区分类型存放的列名"),添加在父类实体,用于说明使用哪个列来区分具体类型;
  3. @DiscriminatorValue(value = "当前类型的标识") 添加到子类实体上,用于说明当前子类的具体类型;

相关实体代码如下:

// 父类
@Entity
// 单表表名
@Table(name = "activity_matcher")
// 当前策略为单表策略
@Inheritance(strategy = InheritanceType.SINGLE_TABLE)
// activity_type 列用于存储对应的类型
@DiscriminatorColumn(name = "activity_type")
@Data
public abstract class BaseActivityMatcher implements ActivityMatcher {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private ActivityMatcherStatus status = ActivityMatcherStatus.ENABLE;
}


// SpecifyUserMatcher 实现类
@Entity
// 使用 SpecifyUser 作为标记
@DiscriminatorValue("SpecifyUser")
public class SpecifyUserMatcher
        extends BaseActivityMatcher
        implements ActivityMatcher {
        // 省略属性和方法
}


// SexMatcher 实现类
@Entity
// 使用 Sex 作为标记
@DiscriminatorValue("Sex")
public class SexMatcher
        extends BaseActivityMatcher
        implements ActivityMatcher {
        // 省略属性和方法
}

@Entity
// 使用 VipLevel 作为标记
@DiscriminatorValue("VipLevel")
public class VipLevelMatcher
        extends BaseActivityMatcher
        implements ActivityMatcher {
        // 省略属性和方法
}

每种策略保存一条数据后,数据库表activity_matcher数据如下图所示:

其中:

  1. activity_type 用于区分当前数据对应的策略类型;
  2. VipLevel类型下,只有 status 和 levels 生效,服务于 VipLevelMatcher,其他全部为 null;
  3. SpecifyUser 类型下,只有 status 和 user_ids 生效,服务于 SpecifyUserMatcher,其他全部为 null;
  4. Sex类型下,只有 status 和 sex 生效,服务于 SexMatcher,其他全部为 null;

单表继承策略,最大的优点便是简单,但由于父类实体和子类实体共用一张表,因此表中会有很多空字段,造成浪费。

3.2.2. Joined 策略

Joined策略,父类实体和子类实体分别对应数据库中不同的表,子类实体的表中只存在其扩展的特殊属性,父类的公共属性保存在父类实体映射表中。

它的使用涉及几个关键注解:

  1. @Inheritance(strategy = InheritanceType.JOINED),添加在父类实体,用于说明当前使用的是 Joined 策略;
  2. @PrimaryKeyJoinColumn(name="子类主键列名称"),添加在子类实体,用于说明使用哪个列来关联父类;

相关实体代码如下:

// 父类
@Entity
@Table(name = "activity_joined_matcher")
// 当前策略为Joined策略
@Inheritance(strategy = InheritanceType.JOINED)
@Data
public abstract class BaseActivityMatcher implements ActivityMatcher {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private ActivityMatcherStatus status = ActivityMatcherStatus.ENABLE;
}


// SpecifyUserMatcher 实现类
@Entity
@Table(name = "user_joined_matcher")
@PrimaryKeyJoinColumn(name = "matcher_id")
public class SpecifyUserMatcher
        extends BaseActivityMatcher
        implements ActivityMatcher {
        // 省略属性和方法
}


// SexMatcher 实现类
@Entity(name = "JoinedSexMatcher")
@Table(name = "sex_joined_matcher")
@PrimaryKeyJoinColumn(name = "matcher_id")
public class SexMatcher
        extends BaseActivityMatcher
        implements ActivityMatcher {
        // 省略属性和方法
}


// VipLevelMatcher 实现类
@Entity(name = "JoinedVipLevelMatcher")
@Table(name = "vip_joined_matcher")
@PrimaryKeyJoinColumn(name = "matcher_id")
public class VipLevelMatcher
        extends BaseActivityMatcher
        implements ActivityMatcher {
        // 省略属性和方法
}

每种策略保存一条数据后,各个表数据如下:
activity_joined_matcher 如下:

user_joined_matcher 如下:

sex_joined_matcher 如下:

vip_joined_matcher 如下:

具有以下特点:

  1. 主表存储各个子类共享的父类数据;
  2. 子表通过字段与主表相关联;
  3. 主表有所有子表的数据,每个子表只有他特有的数据;

从表数据上可以看出,Joined策略可以减少冗余的空字段,但是查询时需要多表连接,效率较低。

3.2.3. 每个实体一个表策略

TABLE_PER_CLASS 策略,父类实体和子类实体每个类分别对应一张数据库中的表,子类表中保存所有属性,包括从父类实体中继承的属性。

它的使用主要涉及以下几个点:

  1. @Inheritance(strategy = InheritanceType.TABLE_PER_CLASS),添加在父类实体,用于说明当前使用的是 TABLE_PER_CLASS 策略;
  2. @GeneratedValue(strategy = GenerationType.AUTO) 不要使用IDENTITY,需要保障每个子类的 id 都不重复;
  3. 抽象父类不需要表与之对应,非抽象父类也需要表用于存储;

相关实体代码如下:

// 父类
@Entity
// 当前策略为 TABLE_PER_CLASS 策略
@Inheritance(strategy = InheritanceType.TABLE_PER_CLASS)
@Data
public abstract class BaseActivityMatcher implements ActivityMatcher {
    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    private Long id;

        // 省略属性和方法
}

// SpecifyUserMatcher 实现类
@Entity
@Table(name = "user_per_class_matcher")
public class SpecifyUserMatcher
        extends BaseActivityMatcher
        implements ActivityMatcher {

        // 省略属性和方法            
}

// SexMatcher 实现类
@Entity
@Table(name = "sex_per_class_matcher")
public class SexMatcher
        extends BaseActivityMatcher
        implements ActivityMatcher {
        // 省略属性和方法
}


// VipLevelMatcher 实现类
@Entity
@Table(name = "vip_per_class_matcher")
public class VipLevelMatcher
        extends BaseActivityMatcher
        implements ActivityMatcher {
        // 省略属性和方法
}

每种策略保存一条数据后,各个表数据如下:
user_per_class_matcher 如下:

sex_per_class_matcher 如下:

vip_per_class_matcher 如下:

具有以下特点:

  1. 每个具体的子类对应一张表,表中存储父类和子类的数据;
  2. 为每个子类生成id,所生成的 id 不重复;

从表数据上可以看出,子类中有相同的属性,则每个子类都需要创建一遍,会导致表结构冗余,影响查询效率。

3.2.4. 小节

三种策略各具特色,都有最佳应用场景,简单如下:

  1. 单表策略。

子类的数据量不大,且与父类的属性差别不大;

ß可以使用单表继承策略来减少表的数量;

  1. Joined 策略。
  2. 子类的属性较多,且与父类的属性差别较大;
  3. 需要一个主表,用于对所有的子类进行管理;
  4. 每个实体一个表策略。
  5. 子类的属性较多,且与父类的属性差别较大;
  6. 子类过于离散,无需统一管理;

当子类过多或数据量过大时,Joined 和 table per class 在查询场景存在明显的性能问题,这个需要格外注意。

3.3. 立即加载&延迟加载

JPA提供了两种加载策略:立即加载和延迟加载。

  1. 一对一关联,默认获取策略是立即加载(EAGER),查询一个对象,会把它关联的对象都查出来初始化到属性中;
  2. 一对多关联,默认获取策略是懒加载(LAZY),即只有在使用到相关联数据时才会查询数据库;

如果默认策略不符合要求,可以通过手工设置注解上 fetch 配置,对默认策略进行重写。

3.3.1. 立即加载

立即加载会在查询主实体类的同时查询它所有关联实体类,并绑定到实体属性上。

立即加载的好处是能够提高查询效率,因为不需要额外的查询操作。但是,使用立即加载会增加数据库的查询负担,查询出所有关联实体类,会导致查询结果的数据量比较大。

实体配置如下:

@Entity
@Table(name = "order_info")
public class Order{
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @OneToMany(cascade = CascadeType.ALL, fetch = FetchType.EAGER)
    @JoinColumn(name = "order_id")
    private List<OrderItem> orderItems = new ArrayList<>();

    @OneToOne(cascade = CascadeType.ALL, fetch = FetchType.EAGER)
    private Pay pay;

    @OneToOne(cascade = CascadeType.ALL, fetch = FetchType.EAGER)
    private Address address;
    // 忽略其他属性和方法
}

测试脚本如下:

Order order = this.orderRepository.findById(this.order.getId()).get();
Assertions.assertNotNull(order);
System.out.println("访问 item");
Assertions.assertEquals(3, order.getOrderItems().size());
System.out.println("访问 address");
Assertions.assertNotNull(order.getAddress().getDetail());
System.out.println("访问 pay");
Assertions.assertNotNull(order.getPay().getPrice());

日志输出如下:

Hibernate: select order0_.id as id1_3_0_, order0_.address_id as address_6_3_0_, order0_.pay_id as pay_id7_3_0_, order0_.status as status2_3_0_, order0_.total_price as total_pr3_3_0_, order0_.total_selling_price as total_se4_3_0_, order0_.user_id as user_id5_3_0_, address1_.id as id1_2_1_, address1_.detail as detail2_2_1_, orderitems2_.order_id as order_id6_4_2_, orderitems2_.id as id1_4_2_, orderitems2_.id as id1_4_3_, orderitems2_.price as price2_4_3_, orderitems2_.product_id as product_3_4_3_, orderitems2_.quantity as quantity4_4_3_, orderitems2_.selling_price as selling_5_4_3_, pay3_.id as id1_5_4_, pay3_.price as price2_5_4_ from order_info order0_ left outer join address address1_ on order0_.address_id=address1_.id left outer join order_item orderitems2_ on order0_.id=orderitems2_.order_id left outer join pay_info pay3_ on order0_.pay_id=pay3_.id where order0_.id=?

访问 item
访问 address
访问 pay

从日志输出可见:

  1. JPA 使用多张表的join,通过一个复杂的 sql 一次性获取了所有数据;
  2. 在访问关联实体时,未触发任何加载操作;
3.3.2. 延迟加载

延迟加载是指在进行数据库查询时,并不会立即查询关联表数据,而是要等到使用时才会去查,这样可以避免不必要的数据库查询,提高查询效率。

延迟加载又分为两种情况:

  1. 表间的延迟加载:在表关联情况下,进行数据库查询时,并不会立即查询关联表,而是要等到使用时才会去查数据库;
  2. 表中属性的延迟加载:比如大型字段blob,需要等到使用时才加载,这样可以避免不必要的数据库查询,提高查询效率;

在此,重点介绍表间关联的延迟加载:

实体代码如下所示:

@Entity
@Table(name = "order_info")
public class Order{
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @OneToMany(cascade = CascadeType.ALL, fetch = FetchType.LAZY)
    @JoinColumn(name = "order_id")
    private List<OrderItem> orderItems = new ArrayList<>();

    @OneToOne(cascade = CascadeType.ALL, fetch = FetchType.LAZY)
    private Pay pay;

    @OneToOne(cascade = CascadeType.ALL, fetch = FetchType.LAZY)
    private Address address;
    // 忽略其他字段和方法
}

查询代码如下:

Order order = this.orderRepository.findById(this.order.getId()).get();
Assertions.assertNotNull(order);
System.out.println("访问 item");
Assertions.assertEquals(3, order.getOrderItems().size());
System.out.println("访问 address");
Assertions.assertNotNull(order.getAddress().getDetail());
System.out.println("访问 pay");
Assertions.assertNotNull(order.getPay().getPrice());

控制台输出如下:

Hibernate: select order0_.id as id1_3_0_, order0_.address_id as address_6_3_0_, order0_.pay_id as pay_id7_3_0_, order0_.status as status2_3_0_, order0_.total_price as total_pr3_3_0_, order0_.total_selling_price as total_se4_3_0_, order0_.user_id as user_id5_3_0_ from order_info order0_ where order0_.id=?

访问 item
Hibernate: select orderitems0_.order_id as order_id6_4_0_, orderitems0_.id as id1_4_0_, orderitems0_.id as id1_4_1_, orderitems0_.price as price2_4_1_, orderitems0_.product_id as product_3_4_1_, orderitems0_.quantity as quantity4_4_1_, orderitems0_.selling_price as selling_5_4_1_ from order_item orderitems0_ where orderitems0_.order_id=?

访问 address
Hibernate: select address0_.id as id1_2_0_, address0_.detail as detail2_2_0_ from address address0_ where address0_.id=?

访问 pay
Hibernate: select pay0_.id as id1_5_0_, pay0_.price as price2_5_0_ from pay_info pay0_ where pay0_.id=?

从日志输出可知,关联实体只有在属性被访问时才会触发自动加载。

延迟加载在聚合更新时极为重要,面对一个大聚合,每次修改只会涉及少量相关联的实体,由于延迟加载机制的保障,对于那些没有必要访问的实体并不会执行实际的加载操作,从而大幅提升性能。

3.4. 按需更新

简单理解按需更新,就是只有在有必要时才会对数据进行更新。

按需更新可以分为两个场景:

  1. 只更新变更实体:在保存一组对象时,只对状态发生变化的实体进行更新;
  2. 只更新变更字段:保存一个实体时,只对状态发生变化的字段进行更新;
3.4.1. 只更新变更实体

在数据保存时,JPA 会自动识别发生变更的实体,仅对变更实体执行 update 语句。

测试代码如下:

Order order = this.orderRepository.findById(this.order.getId()).get();
order.getOrderItems().size(); // 获取未更新
order.getPay().getPrice(); // 获取未更新
order.getAddress().setDetail("新地址"); // 获取并更新
System.out.println("更新数据");
this.orderRepository.save(order);

控制台输出如下:

Hibernate: select order0_.id as id1_3_0_, order0_.address_id as address_6_3_0_, order0_.pay_id as pay_id7_3_0_, order0_.status as status2_3_0_, order0_.total_price as total_pr3_3_0_, order0_.total_selling_price as total_se4_3_0_, order0_.user_id as user_id5_3_0_ from order_info order0_ where order0_.id=?

Hibernate: select orderitems0_.order_id as order_id6_4_0_, orderitems0_.id as id1_4_0_, orderitems0_.id as id1_4_1_, orderitems0_.price as price2_4_1_, orderitems0_.product_id as product_3_4_1_, orderitems0_.quantity as quantity4_4_1_, orderitems0_.selling_price as selling_5_4_1_ from order_item orderitems0_ where orderitems0_.order_id=?

Hibernate: select pay0_.id as id1_5_0_, pay0_.price as price2_5_0_ from pay_info pay0_ where pay0_.id=?

Hibernate: select address0_.id as id1_2_0_, address0_.detail as detail2_2_0_ from address address0_ where address0_.id=?

更新数据
Hibernate: update address set detail=? where id=?

从日志输出可见:

  1. 对聚合中 的实体进行了加载操作;
  2. 但,仅对变更的 address 实体执行了 update 语句;
3.4.2. 只更新变更字段

只更新变更字段,是指只更新实体类中有变化的字段,而不是全部字段。为了实现按需更新,需要在实体类中使用@DynamicUpdate注解,表示只更新有变化的字段。

实体代码见:

@Entity
@Table(name = "order_info")
@DynamicUpdate
public class Order{
    // 其他忽略
}

测试代码如下:

Order order = this.orderRepository.findById(this.order.getId()).get();
order.setUserId(RandomUtils.nextLong()); // 仅更新 user id
System.out.println("更新数据");
this.orderRepository.save(order);

控制台输出如下:

Hibernate: select order0_.id as id1_3_0_, order0_.address_id as address_6_3_0_, order0_.pay_id as pay_id7_3_0_, order0_.status as status2_3_0_, order0_.total_price as total_pr3_3_0_, order0_.total_selling_price as total_se4_3_0_, order0_.user_id as user_id5_3_0_ from order_info order0_ where order0_.id=?

更新数据
Hibernate: update order_info set user_id=? where id=?

如果移除 @DynamicUpdate 注解,控制台输出如下:

Hibernate: select order0_.id as id1_3_0_, order0_.address_id as address_6_3_0_, order0_.pay_id as pay_id7_3_0_, order0_.status as status2_3_0_, order0_.total_price as total_pr3_3_0_, order0_.total_selling_price as total_se4_3_0_, order0_.user_id as user_id5_3_0_ from order_info order0_ where order0_.id=?
更新数据
Hibernate: update order_info set address_id=?, pay_id=?, status=?, total_price=?, total_selling_price=?, user_id=? where id=?

对比输出可知:使用@DynamicUpdate注解后,当修改实体类中的某个字段时,JPA会自动将该字段标记为“脏数据”,并只更新标记为“脏数据”的字段,这样可以减少数据库的IO操作,提高更新效率。

4. 小节

本章从 DDD 聚合生命周期讲起,当我们面对一组高内聚对象时,如何更好的对这一对象组进行维护。

从高内聚对象组视角需要支持:

  1. 对象间的组合关系;
  2. 对象间的继承关系;

从系统性能角度需要支持:

  1. 延迟加载:只有在使用时才触发实体加载;
  2. 按需更新:只对状态变更实体或字段进行更新;

JPA 与 DDD 的==聚合写== 是绝配,但在 “读” 场景 往往会引发各种性能问题。这也是很多公司弃用 JPA 而选择 MyBatis 的主要原因,就其本质并不是框架的错,而是将框架用在了错误的场景。

对于 Command 和 Query 分离架构,最佳组合是:

  1. Command 侧以 DDD 和 JPA 为核心,享受面向对象强大设计力,享受 JPA 所带来的便利性,从而解放双手,提升开发效率;
  2. Query 侧以 DTO 和 MyBatis 为核心,享受 MyBatis 对 SQL 强大控制力,更好的压榨 MySQL 性能,从而降低成本;
责任编辑:武晓燕 来源: geekhalo
相关推荐

2020-09-08 06:32:57

项目低耦合高内聚

2022-03-30 09:50:09

迪米特法则构造器接口

2024-11-14 09:42:32

2023-09-26 01:18:55

解密系统业务

2021-08-26 09:31:40

Nacos配置注册

2022-09-02 08:17:40

MapStruct代码工具

2022-03-18 09:11:56

高并发抢购系统架构

2016-12-02 16:39:17

2016-11-10 18:57:19

双十一高并发

2020-08-18 13:50:04

Tomcat高并发Java

2018-06-29 09:59:26

高并发互联网网卡

2010-04-07 09:25:00

2023-11-06 08:32:17

FastAPIPython

2023-08-05 13:31:20

工厂方法模式对象

2017-08-03 16:31:43

微服务架构领域驱动设计数字化

2016-12-01 17:17:24

2011-08-19 17:47:53

清华哈佛高管

2020-09-03 14:30:40

Tomcat 拆解调优

2016-12-02 11:11:11

2020-02-14 08:05:05

数据网格高扩展易维护
点赞
收藏

51CTO技术栈公众号