怎么在Spring Data中使用JDBC实现DDD聚合

这篇文章将为大家详细讲解有关怎么在Spring Data中使用JDBC实现DDD聚合，文章内容质量较高，因此小编分享给大家做个参考，希望大家阅读完这篇文章后对相关知识有一定的了解。

Spring Data JDBC比JPA更容易理解，比如对象引用特性会很有趣。作为第一个示例，请考虑以下领域模型：

class PurchaseOrder {

 private @Id Long id;
 private String shippingAddress;
 private Set<OrderItem> items = new HashSet<>();

 void addItem(int quantity, String product) {
  items.add(createOrderItem(quantity, product));
 }

 private OrderItem createOrderItem(int quantity, String product) {

  OrderItem item = new OrderItem();
  item.product = product;
  item.quantity = quantity;
  return item;
 }
}
class OrderItem {
 int quantity;
 String product;
}

另外，考虑如下定义的存储库：

interface OrderRepository extends CrudRepository<PurchaseOrder, Long> {

 @Query("select count(*) from order_item")
 int countItems();
}

如果使用商品创建订单，希望所有商品都能保存：

@Autowired OrderRepository repository;

@Test
public void createUpdateDeleteOrder() {

 PurchaseOrder order = new PurchaseOrder();
 order.addItem(4, "Captain Future Comet Lego set");
 order.addItem(2, "Cute blue angler fish plush toy");

 PurchaseOrder saved = repository.save(order);

 assertThat(repository.count()).isEqualTo(1);
 assertThat(repository.countItems()).isEqualTo(2);
 …

此外，如果删除PurchaseOrder，它的所有项目也应该被删除。

 …
 repository.delete(saved);

 assertThat(repository.count()).isEqualTo(0);
 assertThat(repository.countItems()).isEqualTo(0);
}

如果我们需要一个语法上相同但语义上不同的关系呢？上述订单中包含订单条目OrderItem , 当订单删除时，包含的OrderItem 都删除了，但是看看看看下面案例，也是使用包含一个集合：

class Book {
 // …
 Set<Author> authors = new HashSet<>();
}

当书籍绝版时，将Book删除。所有的作者Author也都丢失了。这当然不是你想要的，因为一些作者可能也写过其他书。

怎么办？

让我们看一看存储库实际存在的内容。这与一遍又一遍的问题密切相关：是否应该在JPA中为每个表创建一个存储库？

而正确和权威的答案是“不”。存储库持久聚合并加载聚合。聚合是一个包含各种对象的群，它应始终保持一致。此外，它应始终保持（和加载）在一起。它有一个对象，称为聚合根，它是唯一允许外部访问或引用聚合内部的代理或管理者。聚合根是传递给存储库的，以便持久化聚合里面的对象群。

这提出了一个问题：Spring Data JDBC如何确定什么是聚合的一部分，哪些不是？答案非常简单：非瞬态non-transient 引用都是聚合的一部分，这样就可从聚合根到达聚合内部所有内容。

OrderItem实例是聚合的一部分，因此被删除； Author正好相反，实例不是Book聚合的一部分，因此不应删除。所以不应该从Book内部去引用那些作者Author对象。

问题解决了。好吧，......不是真的。我们仍然需要存储和访问有关Book和Author之间的关系信息。答案可以在领域驱动设计（DDD）中找到，它建议使用ID而不是直接引用。这适用于各种多对X关系。

如果多个聚合引用同一个实体，则该实体不能成为引用它的多个聚合的一部分，因为它只能是其中一个聚合的一部分。因此，任何“多对一”和“多对多”关系都只能通过引用id来建模实现了。

这样可以实现多种目的：

1. 清楚地表示了聚合的边界。

2. 还完全解耦（至少在应用程序的领域模型中）所涉及的两个聚合。

3. 这种分离可以用不同的方式在数据库中表示：

a. 以通常的方式保留数据库，包括所有外键。这意味着必须确保以正确的顺序创建和保留聚合。

b. 使用延迟约束，仅在事务的提交阶段进行检查。这可能会提高吞吐量。它还编纂了最终一致性的版本，其中“最终”与交易结束相关联。这也允许引用从未存在的聚合，只要它仅在事务期间发生。这对于避免大量基础结构代码只是为了满足外键和非空约束可能是有用的。

c. 完全删除外键，实现真正的最终一致性。

d. 将引用的聚合保留在不同的数据库中，甚至可能是No SQL存储。

无论如何，即使Spring Data JDBC也鼓励应用模块化。此外，如果尝试迁移一个具有10年历史的单体，你就会明白它的价值。

使用Spring Data JDBC，您可以建模多对多关系，如下所示：

class Book {

 private @Id Long id;
 private String title;
 private Set<AuthorRef> authors = new HashSet<>();

 public void addAuthor(Author author) {
  authors.add(createAuthorRef(author));
 }

 private AuthorRef createAuthorRef(Author author) {

  Assert.notNull(author, "Author must not be null");
  Assert.notNull(author.id, "Author id, must not be null");

  AuthorRef authorRef = new AuthorRef();
  authorRef.authorId = author.id;
  return authorRef;
 }
}

@Table("Book_Author")
class AuthorRef {
 Long authorId ;
}

class Author {
 @Id Long id;
 String name;
}

请注意额外的类：AuthorRef，它表示有关某个作者的Book聚合的知识。它可能包含有关作者的其他聚合信息，然后实际上会在数据库中重复。考虑到Author数据库可能与Book数据库完全不同，这会产生很多问题。

另请注意，authors是Book 私有字段，AuthorRef实例化在私有方法createAuthorRef中发生。因此聚合之外的任何内容都不能直接访问它。Spring Data JDBC绝不需要这样做，但DDD鼓励这么做。

下面是测试：

@Test
public void booksAndAuthors() {

 Author author = new Author();
 author.name = "Greg L. Turnquist";

 author = authors.save(author);

 Book book = new Book();
 book.title = "Spring Boot";
 book.addAuthor(author);

 books.save(book);

 books.deleteAll();

 assertThat(authors.count()).isEqualTo(1);
}

上述完成了我们设想功能：删除书籍后，并没有将书籍作者数据表数据全部删除，虽然作者是书籍的一个私有字段。

关于怎么在Spring Data中使用JDBC实现DDD聚合就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。