所有Spring Data模块的灵感都来自Domain Driven Design中的“repository”、“aggregate”和“aggregate root”概念。
这些对于Spring Data JDBC可能更重要，因为在某种程度上，它们与使用关系数据库时的正常实践相反：
- 聚合是一组实体，保证在对其进行的原子更改之间保持一致。 一个典型的例子是Order和OrderItems。 Order上的属性（例如，numberOfItems与OrderItems的实际数量一致）在进行更改时保持一致。
- 每个聚合只有一个聚合根，它是聚合的实体之一。 聚合只能通过聚合根上的方法进行操作。 这就是前面提到的原子变化。
- 存储库是对持久性存储的抽象，它看起来像某种类型的所有聚合的集合。
- 对于Spring Data，这意味着您希望每个聚合根有一个Repository。
- 此外，对于Spring Data JDBC，这意味着从聚合根可访问的所有实体都被认为是该聚合根的一部分。
- Spring Data JDBC假设只有聚合具有指向存储聚合的非根实体的表的外键，并且没有其他实体指向非根实体。
- 在当前实现中，从聚合根引用的实体被Spring Data JDBC删除并重新创建。
您可以使用与您的工作和设计数据库的风格相匹配的实现来覆盖存储库方法。
为什么选择 Spring Data JDBC？
Java世界中关系数据库的主要持久化API当然是JPA，它有自己的Spring Data模块。为什么还有另外一个呢？
JPA 做了很多事情来帮助开发人员。除此之外，它还跟踪实体的更改。它为您执行延迟加载。它允许您将广泛的对象构造映射到同样广泛的数据库设计。
这太棒了，让很多事情变得非常简单。只需看一下基本的 JPA 教程即可。但对于为什么 JPA 会做某件事，常常会让人感到非常困惑。此外，概念上非常简单的事情对于 JPA 来说却变得相当困难。
Spring Data JDBC 的目标是通过采用以下设计决策，在概念上变得更加简单：
- 如果加载实体，SQL 语句就会运行。完成此操作后，您就拥有了一个完全加载的实体。不进行延迟加载或缓存。
- 如果您保存一个实体，它就会被保存。如果你不这样做，它就不会。没有脏跟踪，也没有会话。
- 有一个关于如何将实体映射到表的简单模型。它可能只适用于相当简单的情况。如果您不喜欢这样，您应该编写自己的策略。Spring Data JDBC 对使用注释自定义策略仅提供非常有限的支持。
详细点击标题