这是我的场景，
我们正在开发一个订购应用程序，其产品应该来自另一个系统，该系统具有产品目录和产品供应性规则。我们通过网络服务与他们沟通。
形成获取产品的服务请求涉及更多的业务逻辑，为此我必须参考其他实体，如地址、客户资料、营销策略规则等。
如果我想在产品存储库中进行调用以填充产品实体，那么引用其他实体并在产品存储库中具有如此复杂的逻辑是否合适？
他们中的一些人建议使用 Application Service ，但根据我的理解，我不清楚应用程序服务与域和基础设施对话以完成特定任务。而且它不会包含任何业务逻辑。
什么是合适的地方和最好的方法？
我建议使用域服务并使用适配器调用 webservice 来实现它。
存储库策略意味着您需要在订购有界上下文中将产品作为聚合。但产品类别和定价不是订购有界上下文的核心领域。因此，您可能不需要产品作为聚合。我认为您只需要一些简单的值对象来聚合记录预订的产品。将其他产品的东西隐藏在域服务后面。
一个很好的例子是 eric evans 的 DDD 书中提到的 cargo RoutingService。
根据 DDD 存储库不应包含任何业务逻辑。它们应该是您的域层访问和操作持久数据的简单工具。所有业务逻辑都应该由域服务、聚合、实体或值对象持有。
恕我直言，因为这在所有 DDD 手册中都写得很清楚，我建议您（重新）阅读它们。
祝你好运！