Domain driven design 在实体中使用基础架构服务或存储库

我有一个实体，交换。Exchange需要在启动时填充VO列表CurrencyPair。CurrencyPair集合作为主数据存储在数据库中，并有一个名为ICurrencyPairRepository的存储库来获取所有可用的货币对。因此，我希望在应用程序启动后在Exchange实体中获取CurrencyPair集合

我的问题是，我可以直接将ICurrencyPairRepository的实现注入Exchange吗？或者应该有一个从存储库获取currencypair的基础设施服务实现吗？当然，icurrencypair存储接口在域层内，它的实现在基础设施层

还是应该在Exchange中插入应用程序服务？我们是否只允许将域服务注入实体，或者也可以注入其他服务/存储库

用例：

在启动时，交易所需要获取应用程序中允许交易的所有货币对。每当一个新订单进入交换时，它都包含它想要交易的货币对。然后，交易所需要检查这对货币是否允许交易。如果是，则转发订单，否则放弃请求

---

由于Exchange是聚合根目录，我可以从应用程序启动的位置对其进行初始化，并为其提供一组货币对，但是我很想知道在一个实体中允许注入什么，在这种情况下，实体也是聚合根。

对于一些人来说，直接将存储库依赖项注入实体是可以接受的，我个人非常不喜欢这种解决方案。在处理基础架构SRP冲突时，很难关注行为

---

我通常尝试做的是一个应用程序服务，它检索实体所需的全部信息。。。然后，我真的可以测试和编写行为。

一般来说，不建议向任何实体注入服务/存储库。你也可以发布你的用例吗？Hippoom评论的理由是，向实体添加服务和存储库会使实体的创建和重构变得更加困难，也会使其行为更难理解。如果您能给出一个Exchange中使用CurrencyPair集合的方法的示例，这将对您的问题有所帮助。@WaqasShah请查看DDD中值对象、存储库和应用程序服务的定义。从你的问题判断，他们可能不是你想象的那样。聚合的概念也有帮助。我已经提供了用例，请查看。此外，我确实了解VO、应用程序服务和存储库，但我只想了解在使用实体和服务时约束我们的边界。ThankSenties很少需要使用服务，因为它们通常在自己的聚合中以其他实体和VO的形式拥有它们持久需要的一切，并且它们偶尔需要作为方法参数传递给它们。域对象无法引用应用程序服务，因为它们位于不同的、不可访问的层中。