DDD存储库属于哪个层？

Question

在他的DDD书中，Evans提出了分层体系结构的思想，特别是业务逻辑应该局限于域层，并与UI/persistence/其他关注点分离。他还引入了存储库模式，作为对实体和值对象进行抽象访问和持久存储的手段。对我来说，还不清楚的是：

1. 哪一层存储库属于哪个层:域层、持久化层还是中间的什么东西？(如果它低于域层，它将违反分层体系结构原则，因为它依赖于它存储的域对象)
2. 实体、值对象或域服务可以调用存储库吗？
3. 存储库应该从存储技术(如果它们属于域层)中抽象，还是能够利用这些存储技术？
4. 存储库可以包含业务逻辑吗？
5. 你是否在实践中应用了这些约束，对你的项目质量有什么影响？

(我最感兴趣的是DDD视角)

Answer 1

1. 存储库接口属于域层。存储库实现应该在其他地方，但文献尚不清楚。选项包括:基础结构层(可能是最符合DDD规则的层)；应用层；持久层；存储层或子层。
2. 不是的。这将违反DDD驱动的分层体系结构，并可能造成循环依赖。
3. 现在推荐的做法是定义一个从持久性技术中抽象出来的存储库接口。回购促进OTOH不是。显然，应用程序服务应该使用回购接口。
4. 存储库不应包含业务逻辑。但是，它们可能包含查询逻辑。有些人可能将查询逻辑视为业务逻辑，特别是如果查询是一个复杂的查询。如果您有复杂的回购查询，可能您的聚合比它应该的要大，或者您过度使用了查询语言功能。使用存储库来报告需求是一种反模式。
5. 在我们的组织中，我们将存储库接口与域层中的实体放在一起。App服务直接使用实体、VOs和存储库(通过接口)。我们使用JpaRepository接口。关于答案(1)，这个替代方案的好处是您不需要提供存储库实现--它是Spring框架自动提供给您的。

我的答案主要受谷子DDD的模式、原理与实践的影响。

Answer 2

根据本样本样本，您可以在域层拥有一个存储库作为接口(CargoRepository)，在基础结构层中有一个实际的实现(CargoRepositoryHibernate)。

分层架构图片(也来自DDD蓝皮书)：