这是我的方案，
我们正在开发一种订购应用程序，其中产品应来自另一个系统，该系统具有产品目录和产品可用性规则。我们通过网络服务与他们沟通。
形成服务请求以获取产品涉及更多业务逻辑，我必须参考其他实体，如地址，客户资料，营销策略规则等。
如果我想在产品库中调用以填充产品实体，是否适合引用其他实体并在产品库中具有如此复杂的逻辑？
他们中的一些人建议使用应用服务，但我不清楚，因为我的理解应用服务与域和基础设施的谈话来完成一项特定的任务。它不会有任何业务逻辑。
适当的地方和最佳方式是什么？
答案 0 :(得分：1)
我建议使用域服务，并使用适配器调用webservice实现它。
存储库策略意味着您需要在订购有界上下文中将产品作为聚合。但产品类别和定价并不是订购有界背景的核心领域。因此，您可能不需要产品作为聚合。我认为你只需要一些简单的价值对象来聚合来记录预订的产品。隐藏域名服务背后的其他产品。
一个很好的例子是埃里克·埃文斯的DDD书中提到的货物路线服务。
答案 1 :(得分：0)
根据DDD存储库不应包含任何业务逻辑。它们应该是您的域层访问和操作持久数据的简单工具。所有业务逻辑都应由域服务，聚合，实体或值对象保存。
得到应有的尊重，因为在所有DDD手册中都写得非常清楚，我建议你（重新）阅读它们。
祝你好运！答案 2 :(得分：0)
关于架构的好讨论：
Domain driven design repository implementation in infrastructure layer
应用层很好，但它们的接口必须在核心项目中