domain-driven-design - 如何干净地(物理地)将域层与 Spring 数据代码分开？

Question

在我的 DDD-by-the-book 应用程序中，我的域层中有一个这样的存储库定义:

public interface CustomerRepository {
    Customer findById(long id);
    ...
}

数据库集成层包含此接口(interface)的实现，如下所示:

public class CustomerDao implements CustomerRepository {
    public Customer findById(long id) {
        // access EntityManager or JDBCTemplates or ...
    }
}

每层都有一个模块，数据库模块依赖于域和所有集成库(例如hibernate)，而域模块依赖于任何东西。因此，正如 DDD 所建议的那样，我们对关注点进行了清晰的分离，并且没有域的“技术”依赖关系。因此，我可以通过创建适当的存储库实现从数据库切换到内存中的持久性。使用的实现是在我的应用程序层中配置的。

为数据库访问实现存储库是很糟糕的，因为我们有 Spring Data，所以不再需要了。要使用 spring 数据，我必须像这样定义一个存储库。

public interface CustomerRepository implements Repository<Customer, Long> {
    ....

这意味着，由于存储库接口(interface)定义在我的域层中，我现在的域层依赖于“技术”库。当切换到内存实现时，我的应用程序中也会有 spring-data 类。我想，这有点臭。

你怎么看？你怎么处理这个？是否可以使用 Spring 数据而不依赖于我的域层？

谢谢

(顺便说一句:我的业务对象是 JPA 注释的，因此我的域模块依赖于 javax.persistence。但我可以忍受这个，主要是因为 javax.persistence 只包含注释而没有实现。所以这是一个“逻辑”而不是“技术”依赖。我想对 spring-data-annotation 模块的依赖会少一些。)

Answer 1

最近，我在使用 Spring Data 并遵循 Onion 架构进行项目时遇到了同样的挑战。下面是我的食谱:

在不引用 Spring Data 的情况下定义 CustomerRepository(在您的域层中):

public interface CustomerRepository {
  Customer findById(long id);
  // ..
}

在你的数据访问层定义 CustomerDao，它依赖于 Spring Data:

public CustomerDao implements Repository<Customer, Long> { }

定义域 CustomerRepository 的实现，它将所有调用委托(delegate)给 CustomerSpringDataRepository，并且将有一个由 Spring 注入(inject)的 CustomerDao 实例:

public class CustomerRepositoryImpl implements CustomerRepository {
   @Autowired private CustomerDao dao;

   public Customer findById(long id) { return doa.findById(id); }
}

在你的领域层注入(inject) CustomerRepository

使用这种方法:

您的领域层不依赖于 Spring Data，只有数据访问层依赖于 Spring Data

您的域不依赖于数据访问层，这意味着没有基础设施(例如 Spring Data)类出现在域

中

我创建了 a sample project using Spring Data and the Onion architecture遵循上述方法。