使用 Spring Data 构建存储库非常容易。您需要做的就是声明您的存储库接口并让它扩展 Spring Data 接口JpaRepository。但是，这也很容易意外地为本地实体创建存储库（如果您的开发人员不熟悉 DDD 但熟悉 JPA，则可能会发生这种情况）。因此，我总是像这样声明自己的基础存储库接口：

@NoRepositoryBean // <1>
public interface BaseRepository<Aggregate extends BaseAggregateRoot<ID>, ID extends Serializable> // <2>
        extends JpaRepository<Aggregate, ID>,  // <3>
                JpaSpecificationExecutor<Aggregate> { // <4>

    default @NotNull Aggregate getById(@NotNull ID id) { // <5>
        return findById(id).orElseThrow(() -> new EmptyResultDataAccessException(1));
    }
}

1. 这个注解告诉 Spring Data 不要试图直接实例化这个接口。
2. 我们将存储库服务的实体限制为仅聚合根。
3. 我们扩展JpaRepository.
4. 我个人更喜欢规范而不是查询方法。我们稍后会回到为什么。
5. 内置findById方法返回一个Optional. 在许多情况下，当您通过其 ID 获取聚合时，您会假设它存在。必须处理Optional每一次都是浪费时间和代码，因此您不妨直接在存储库中执行此操作。

有了这个基本接口，Customer聚合根的存储库可能看起来像这样：

public interface CustomerRepository extends BaseRepository<Customer, CustomerId> {
    // No need for additional methods
}

这就是检索和保存聚合所需的全部内容。现在让我们看看如何实现查询。

查询方式及规格

在 Spring Data 中创建查询最直接的方法是定义仔细命名的findBy-methods（如果您不熟悉，请查看Spring Data 参考文档）。

我发现这些对于仅基于一个或两个键查找聚合的简单查询很有用；例如，在 a 中PersonRepository可以调用一个方法findBySocialSecurityNumber，在 a 中CustomerRepository可以调用一个方法findByCustomerNumber。但是，对于更高级或更复杂的查询，我尽量避免使用findBy-methods。

我这样做主要有两个原因：首先，方法名称往往会变得很长，并且无论在哪里使用都会污染代码。

其次，来自应用程序服务的非常具体的需求可能会潜入存储库，一段时间后，您的存储库会充满查询方法，这些方法几乎可以完成相同的工作，但变化很小。我想保持我的域模型尽可能干净。相反，我喜欢使用*规范*来构建我的查询。

当您按规范查询时，您首先要构建一个规范对象，该对象描述您想要从查询中得到的结果。规范对象也可以使用逻辑运算符*and*和*or*进行组合。为了获得最大的灵活性，我尽量保持我的规格尽可能小。如果需要，我会为常用的规格组合创建复合规格。

Spring Data 内置了对规范的支持。要创建规范，您必须实现Specification接口。这个接口依赖于 JPA Criteria API，所以如果你以前没有使用过它，你需要熟悉它（这里是 Hibernate 的关于它的文档）。

该Specification接口包含一个您必须实现的方法。它生成一个 JPA Criteria 谓词，并将创建所述谓词所需的所有必要对象作为输入。

创建规范的最简单方法是创建规范工厂。最好用一个例子来说明这一点：

public class CustomerSpecifications {

    public @NotNull Specification<Customer> byName(@NotNull String name) {
        return (root, query, criteriaBuilder) -> criteriaBuilder.like( // <1>
            root.get(Customer_.name), // <2>
            name
        );
    }

    public @NotNull Specification<Customer> byLastInvoiceDateAfter(@NotNull LocalDate date) {
        return (root, query, criteriaBuilder) -> criteriaBuilder.greaterThan(root.get(Customer_.lastInvoiceDate), date);
    }

    public @NotNull Specification<Customer> byLastInvoiceDateBefore(@NotNull LocalDate date) {
        return (root, query, criteriaBuilder) -> criteriaBuilder.lessThan(root.get(Customer_.lastInvoiceDate), date);
    }

    public @NotNull Specification<Customer> activeOnly() {
        return (root, query, criteriaBuilder) -> criteriaBuilder.isTrue(root.get(Customer_.active));
    }
}

1. 这里我只是做一个简单的like查询，但在现实世界的规范中，您可能希望更彻底，注意通配符、大小写匹配等。
2. Customer_是由 JPA 实现（例如Hibernate）生成的元模型类。

然后，您将按以下方式使用规范：

public class CustomerService {

    private final CustomerRepository repository;
    private final CustomerSpecifications specifications;

    public CustomerService(CustomerRepository repository, CustomerSpecifications specifications) {
        this.repository = repository;
        this.specifications = specifications;
    }

    public Page<Customer> findActiveCustomersByName(String name, Pageable pageable) { // <1>
        return repository.findAll(
            specifications.byName(name).and(specifications.activeOnly()), // <2>
            pageable
        );
    }
}

1. 永远不要编写返回没有上限的结果集的方法（至少在生产代码中）。要么使用分页（就像我在这里做的那样），要么对查询可以返回的记录数使用有限且合理的限制。
2. 这里使用运算符将两个规范组合在一起and。

关于存储库和 QueryDSL 的说明

Spring Data 还支持QueryDSL。在这种情况下，您不是使用规范，而是直接使用 QueryDSL 谓词。设计原则几乎相同，因此如果您觉得 QueryDSL 比 JPA Criteria API 更舒服，那么您没有理由改变。

规格和测试

使用规范来支持查询方法有一个明显的缺点，这与单元测试有关。Criteria由于规范在后台使用了 JPA Criteria API，因此在不构造和分析其 JPA 谓词的情况下，没有简单的方法对给定对象的内容进行断言 - 这是一个重要的过程。

但是，有一些方法可以解决这个问题。最明显的方法是在单元测试中模拟存储库时忽略对传入规范的检查，并使用单独的集成测试来测试你的规范，例如使用内存中的 H2 数据库。在许多情况下，这可能已经足够好了。