我有一个应用程序服务（AppService）和一个从外部数据提供程序读取数据的基础结构存储库（InfraRepo）。 AppService调用InfraRepo并将数据返回给客户端。 我有以下要求：我有一些过滤条件和业务逻辑。为此，我创建了一个域服务（DomainService）并将其注入InfraRepo。一旦我从外部数据提供者（在InfraRepo中）检索数据，我就调用域服务，在那里传递数据，然后返回结果。然后我将结果返回给应用服务，该服务映射到Dto并返回给客户端。 在基础架构存储库中调用域服务是否正确。
答案 0 :(得分：2)
存储库实现位于较低的Infrastructure / Persistence / Data / ...层。如果一个Repository实现调用域服务，则意味着您将该类决策委派给较低层。顺便提一下，你也可以完全合法地使用而不是来调用服务的另一个Repo实现。
这有点奇怪，因为在任何使用案例中，域层通常都是始终想要调用的东西。让基础设施负责打电话或不打电话给域名。
域服务不是过滤逻辑的最佳位置。通常将过滤器作为参数传递给Repository或Query Service方法。
可以在域服务中找到业务逻辑，但如果您可以将其放在相关的实体或值对象中，则会更好。
长话短说，你可以在这里找到更好的责任分配。准确地说明哪一个很难，因为我们错过了你真正想要这个域名服务的细节。
答案 1 :(得分：1)
似乎我们可以在讨论中将几个概念放在一起来解决这个问题，并强调每个概念的好处，而不是纯粹讨论DDD。
根据您对DDD的熟悉程度，此article提供了对DDD的良好概述。它将DDD构建块称为：实体，值对象，聚合（根），服务，存储库和工厂。在这个问题中，讨论了服务和存储库。没有讨论实体或价值对象;因此，我不确定存储库返回的数据。
这些元素如何相互作用可以通过讨论here的洋葱架构来解决。在这种情况下，它声明域应该是核心，然后是域服务，然后是应用程序服务，最后是外层，即UI，测试和基础结构。在此模型中，数据访问（存储库）是基础结构。所以关键是依赖关系从外层流向内层;也就是说，域不依赖于其他任何东西。这与传统的3层体系结构形成对比，在传统的3层体系结构中，所有内容都依赖于数据访问代码，UI和数据访问代码之间存在业务代码。洋葱架构会说存储库（InfraRepo）属于外层，下一层是应用服务，下一层属于域服务。因此，AppService永远不会调用InfraRepo，因为控件永远不会流到外层，只能来自外层。相反，AppService会调用DomainService来调用域（即业务逻辑）。域将利用它为数据访问定义的抽象（接口或纯虚拟类）。 InfraRepo将实现这种抽象，理想情况下，域类将使用IoC容器来获取InfraRepo实例，同时只知道接口。也就是说，IoC容器在DDD的构建块中就像上面提到的工厂一样。
SOLID原则已存在一段时间，并处理类设计的更精细方面，以允许灵活和健壮的代码。在这种情况下，依赖性倒置原则可以通过IoC容器实现，作为其使用的附加参数。此外，存储库接口的定义应牢记接口隔离原则。