tch*_*ick 4 domain-driven-design ddd-repositories spring-data
在我的DDD-by-the-book应用程序中,我在域层中有一个这样的存储库定义:
public interface CustomerRepository {
Customer findById(long id);
...
}
Run Code Online (Sandbox Code Playgroud)
数据库集成层包含此接口的实现,如下所示:
public class CustomerDao implements CustomerRepository {
public Customer findById(long id) {
// access EntityManager or JDBCTemplates or ...
}
}
Run Code Online (Sandbox Code Playgroud)
每个层都有一个模块,数据库模块依赖于域和所有集成库(例如hibernate),而域模块依赖于任何东西.因此,我们对问题进行了清晰的分离,并且没有DDD提出的域的"技术"依赖性.因此,我可以通过创建适当的存储库实现从数据库切换到内存中持久性.使用的实现在我的应用程序层中配置.
为数据库访问实现存储库很糟糕,因为我们有Spring Data,所以不再需要了.要使用spring数据,我必须像这样定义一个存储库.
public interface CustomerRepository implements Repository<Customer, Long> {
....
Run Code Online (Sandbox Code Playgroud)
这意味着,由于存储库接口定义在我的域层中,我现在将我的域层依赖于"技术"库.切换到内存中实现时,我的应用程序中也会有spring-data类.我想,这有点味道.
你觉得怎么样?你怎么处理这个?是否可以使用spring数据并且没有来自我的域层的依赖?
谢谢
(顺便说一句:我的业务对象的JPA注释,因此我的域名模块具有依赖性javax.persistence但我可以用这个活,主要是因为javax.persistence只包含注释,没有实现原来这是相当"逻辑"不是.一个"技术"依赖.我认为对spring-data-annotation模块的依赖会闻起来更少.)
最近,在使用Spring Data进行项目并遵循Onion架构时,我遇到了同样的挑战.以下是我的食谱:
定义CustomerRepository(在您的域层中)而不引用Spring Data:
public interface CustomerRepository {
Customer findById(long id);
// ..
}
Run Code Online (Sandbox Code Playgroud)在数据访问层中定义CustomerDao,它依赖于Spring Data:
public CustomerDao implements Repository<Customer, Long> { }
Run Code Online (Sandbox Code Playgroud)定义域CustomerRepository的实现,它将所有调用委托给CustomerSpringDataRepository,并且将由Spring注入CustomerDao实例:
public class CustomerRepositoryImpl implements CustomerRepository {
@Autowired private CustomerDao dao;
public Customer findById(long id) { return doa.findById(id); }
}
Run Code Online (Sandbox Code Playgroud)在您的域层中注入CustomerRepository
用这种方法:
我已按照上述方法使用Spring Data和Onion架构创建了一个示例项目.