用例（应用程序服务）的接口？
Interface for use cases (application services)?
在遵循 DDD 原则的六边形架构时，用例或应用程序服务是否应该有接口和实现？例如，用例“删除视频”，它是否应该有实现该接口的 IDeteVideo（接口）和 DeletVideoImpl（实现）？
如果答案是肯定的，那么用例的接口应该在哪里，是在领域层还是在应用层？很明显，实现应该始终在应用层。
我认为用例不是经常变化的东西，所以在我看来我认为没有必要有接口，有实现就足够了。但是在六边形架构和 DDD 原则方面，是否有关于此的说明？
提前致谢。
使用hex arch实现DDD时，应用服务的接口是驱动端口（用例边界，六边形的左边缘）。
六边形内部分为两部分：应用程序服务实现和域。
Should Use Cases or Application Services have interfaces and
implementations when following a hexagonal architecture with ddd
principles?
简而言之，您通常用例不需要接口（在 Clean Architecture 中也称为交互器），因为您的主要适配器（您的 hexagone 的客户端）依赖于 hexagone天生的。
请注意，在制作 辅助 适配器（您的用例使用的外部组件）时，您仍然需要它，因为您的六边形不得依赖于任何辅助适配器。
但是，在以下情况下，您可能仍需要用例接口：
您希望能够对您的主要适配器（尽管被认为是不起眼的对象）进行单元测试，您可以通过其接口stub/mock您的用例。
您可能想为用例尝试多种替代方案以便进行实验，在这种情况下，它将充当有意义的抽象。
If the answer is yes, where should the interfaces of the use cases be ? In the domain layer or in the application layer?
它应该放在六边形内部，在应用层级别，因为每个接口都定义了一个应用程序服务。
我认为不需要为您的应用程序服务提供接口。由于它们通常会编排特定的应用程序用例，因此不应该对同一类型的工作流进行不同的实现。此外，它们不应该依赖于基础设施本身，而是通过调用存储库、域服务或聚合上的操作来编排需要发生的操作的工作流。
更重要的是要确保您的应用程序服务仅访问接口而不是依赖于基础架构的具体实现。这意味着应用程序服务应该只依赖接口来使用存储库或访问其他基础设施的组件（例如，向外部系统发出请求的服务组件）。
但是，如果您的应用程序服务（或用例）有接口，则应在应用层定义这些接口。这与应该驻留在域层中的域接口（例如存储库接口）的规则相同。
我也是这么想的。由于每个 应用程序服务 只有一个用例，因此您不需要接口。这来自我与不同团队的实践，在这些团队中我们没有仅用于一种实现的接口。另外，我同意 application service 接口（如果你有）应该在应用层定义。
但是我在基础设施层也看到了它们。
在遵循 DDD 原则的六边形架构时，用例或应用程序服务是否应该有接口和实现？例如，用例“删除视频”，它是否应该有实现该接口的 IDeteVideo（接口）和 DeletVideoImpl（实现）？
如果答案是肯定的，那么用例的接口应该在哪里，是在领域层还是在应用层？很明显，实现应该始终在应用层。
我认为用例不是经常变化的东西，所以在我看来我认为没有必要有接口，有实现就足够了。但是在六边形架构和 DDD 原则方面，是否有关于此的说明？
提前致谢。
使用hex arch实现DDD时，应用服务的接口是驱动端口（用例边界，六边形的左边缘）。
六边形内部分为两部分：应用程序服务实现和域。
Should Use Cases or Application Services have interfaces and implementations when following a hexagonal architecture with ddd principles?
简而言之，您通常用例不需要接口（在 Clean Architecture 中也称为交互器），因为您的主要适配器（您的 hexagone 的客户端）依赖于 hexagone天生的。
请注意，在制作 辅助 适配器（您的用例使用的外部组件）时，您仍然需要它，因为您的六边形不得依赖于任何辅助适配器。
但是，在以下情况下，您可能仍需要用例接口：
您希望能够对您的主要适配器（尽管被认为是不起眼的对象）进行单元测试，您可以通过其接口stub/mock您的用例。
您可能想为用例尝试多种替代方案以便进行实验，在这种情况下，它将充当有意义的抽象。
If the answer is yes, where should the interfaces of the use cases be ? In the domain layer or in the application layer?
它应该放在六边形内部，在应用层级别，因为每个接口都定义了一个应用程序服务。
我认为不需要为您的应用程序服务提供接口。由于它们通常会编排特定的应用程序用例，因此不应该对同一类型的工作流进行不同的实现。此外，它们不应该依赖于基础设施本身，而是通过调用存储库、域服务或聚合上的操作来编排需要发生的操作的工作流。
更重要的是要确保您的应用程序服务仅访问接口而不是依赖于基础架构的具体实现。这意味着应用程序服务应该只依赖接口来使用存储库或访问其他基础设施的组件（例如，向外部系统发出请求的服务组件）。
但是，如果您的应用程序服务（或用例）有接口，则应在应用层定义这些接口。这与应该驻留在域层中的域接口（例如存储库接口）的规则相同。
我也是这么想的。由于每个 应用程序服务 只有一个用例，因此您不需要接口。这来自我与不同团队的实践，在这些团队中我们没有仅用于一种实现的接口。另外，我同意 application service 接口（如果你有）应该在应用层定义。 但是我在基础设施层也看到了它们。