我从DDD开始，你可以想象我的大脑沸腾了。
我的问题与我的域对象（实体，VO，...）有关，它代表我的域概念/逻辑以及如何持久/检索它们。
蓝皮书说，存储库是一种表示域对象集合的方式，负责与基础架构层进行通信。我在一些帖子中也读到了infrastructura层，你必须使用hibernate，JPA或其他什么。
然后我看到这个Spring-data-jpa示例 http://spring.io/guides/gs/accessing-data-jpa/ 我变得疯了
该口号称Spring-data-jpa可以轻松创建存储库，之前的示例似乎将JPA注释合并到域对象中（ customer）。
样品对吗？或者我是对的？
如果我是对的，域和基础设施必须分开，这意味着要存储我必须拥有的客户：
- 一个
Customer 我的域层中的类（代表客户并具有所有逻辑操作）
- 一个
CustomerRepository un我的域层（从基础架构层检索或存储客户）
- 一个
Customer 基础结构层中的类，可能使用@Entity注释
- 一些
CustomerReposityJPA 知道如何从数据库中存储/检索客户。
谢谢你的任何澄清。
在DDD中，存储库是参与域的对象，但实际上是抽象出一些后备存储。
如果使用JPA注释注释域对象，则持久性机制已渗入您的域。您已将域结构与持久性结构联系起来，这是不理想的。
你的 JpaCustomerRepository （农具 ICustomerRepository）可以映射未注释的域类（Customer）进入带注释的JPA表示 - JPA客户。这样可以将注释保留在域类之外，因此更清晰。它允许您独立于域结构改变JPA持久性结构。这种好处的代价是映射代码的复杂性。
interface ICustomerRepository {}
class JpaCustomerRepository implements ICustomerRepository {
void save(Customer customer) {
JpaCustomer jpaCustomer = map(customer);
save(jpaCustomer);
}
}
class Customer {}
class JpaCustomer {}
我看不到您发布的链接，我从未将域驱动设计应用于Java世界。
从理论上讲，你需要的是什么 Customer 在域层中聚合。在您的域层中，存储库（用作接口）有空间，因此您将拥有 ICustomerRepository。
对于常见的持久性问题，您可能会有四个原型：
GetById(CustomerId id);
Add(Customer c);
Delete(Customer c);
Update(Customer c);
在基础结构层中，您将提供正文（例如 CustomerRepository），在infrastracture层，你可以结合自己的技术（例如JPA）。
域层必须完全不知道基础结构中使用的技术。这样做你可以完全改变实现细节（几乎没有麻烦）。