我不太了解 DDD 存储库模式，但 Spring 中的实现让我感到困惑。
public interface PersonRepository extends JpaRepository<Person, Long> { … }
由于接口扩展了 JpaRepository（或 MongoDBRepository...），如果您从一个 db 更改为另一个，您也必须更改接口。
对我来说，接口是用来提供一些抽象的，但在这里它不是那么抽象......
你知道为什么 Spring-Data 会这样工作吗？
【问题讨论】：
标签： spring domain-driven-design nosql repository-pattern spring-data
在 Spring Data 的 M2 之前，我们要求用户扩展 JpaRepository，原因如下：
Repository、CrudRepository 或类似的好处超过了您在刚刚描述的极端案例中所付出的努力。您可以在命名空间中使用 exclude 和 include 元素来对此进行更细粒度的控制。@Transactional 注释它们来将事务性应用于 CRUD 方法。这一决定又是由AnnotationTransactionAttributeSource 用于查找事务配置的算法驱动的。因为我们希望通过在具体存储库接口中重新声明 CRUD 方法并在其上应用 @Transactional 来为用户提供重新配置事务的可能性。对于 RC1，我们决定实现自定义 TransactionAttributeSource，以便能够将注释移回存储库 CRUD 实现。长话短说，归结为：
从 RC1 开始，不再需要扩展商店特定的存储库接口，除了您想要...
List 的访问findAll(…) 而不是基于Iterable 的访问（尽管您可以简单地在公共基础接口中重新声明相关方法以返回Lists好）saveAndFlush(…) 等。一般来说，自 RC1 以来，您在 CRUD 方法的公开方面更加灵活，因为您甚至可以仅扩展 Repository 标记接口并有选择地添加您想要公开的 CRUD 方法。由于支持实现仍将实现PagingAndSortingRepository 的所有方法，我们仍然可以将调用路由到实例：
public interface MyBaseRepository<T, ID extends Serializable> extends Repository<T, ID> {
List<T> findAll();
T findOne(ID id);
}
public interface UserRepository extends MyBaseRepository<User, Long> {
List<T> findByUsername(String username);
}
在该示例中，我们定义 MyBaseRepository 以仅公开 findAll() 和 findOne(…)（将被路由到实现 CRUD 方法的实例中）并且具体存储库向两个 CRUD 方法添加一个查找器方法。
有关该主题的更多详细信息，请咨询reference documentation。
【讨论】：
这背后的原因在这篇博文http://blog.springsource.com/2011/02/10/getting-started-with-spring-data-jpa/ 中已经很清楚地说明了。
定义这个接口有两个目的：首先，通过扩展 JpaRepository，我们在我们的类型中获得了一堆通用的 CRUD 方法，这些方法允许保存帐户，删除它们等等。其次，这将允许 Spring Data JPA 存储库基础架构扫描此接口的类路径并为其创建一个 Spring bean。
如果您不信任与来源如此接近的来源（双关语），那么阅读这篇文章可能是个好主意http://www.brucephillips.name/blog/index.cfm/2011/3/25/Using-Spring-Data-JPA-To-Reduced-Data-Access-Coding。
我不需要编写代码的是 PersonRepository 接口的实现。 Spring 将创建此接口的实现，并使 PersonRepository bean 可用于自动装配到我的 Service 类中。 PersonRepository bean 将具有所有标准 CRUD 方法（将是事务性的）并返回 Person 对象或 Person 对象的集合。因此，通过使用 Spring Data JPA，我节省了编写自己的实现类。
【讨论】：
你是对的，从外部的角度来看，接口是对所有实现类都有效的东西的抽象。
这正是这里发生的事情：
但是 JpaRepository 和 MongoDBRepository 没有任何共同之处，除了在公共超级接口中定义的东西：
所以对我来说它看起来很正常。
如果您使用实现 Repository 的类，那么如果您希望能够从 JPA 实现切换到基于 Document 的实现，请使用 PagingAndSortingRepository 或 Repository（抱歉，我无法想象这样的用例 - 无论如何）。当然，您的 Repository 实现应该实现正确的接口（JpaRepository、MongoDBRepository），具体取决于它是什么。
【讨论】：