C# 应该在域或服务层中定义DTO接口吗？

我希望adpaters向cart服务传递一个公共接口。我读过，接口应该在域层，DTO应该在服务层定义，这似乎与我有冲突。您不希望域层引用定义DTO的服务层

我错过了什么？或者像我在图中所做的那样，让接口与服务层中的DTO一起工作，这样可以吗

---

因此，如果您使用分层架构模式（我想您是这样做的），那么应该考虑该模式的一个基本特性。此属性表示不同层中的模块（类）之间的“使用”依赖关系的特定顺序，尤其是某一层中的模块应“使用”（依赖）下一底层或多层中的模块或抽象。我提到层是因为可以有一些宽松的约束，这些约束不仅允许使用最近底层的类，还允许使用给定层下面的所有层。对于向上的依赖关系，约束是非常严格和明确的——这是不允许的，否则它不是分层体系结构，而是其他东西，因为它消除了分层体系结构应该带来的质量属性。从逻辑上讲，在域层内使用来自服务层的DTO意味着向上依赖，这违反了分层体系结构约束

至于接口，分层体系结构的另一个基本特性是各层应通过抽象相互隔离。这里的抽象可能意味着一些公共契约（API、接口等），这些契约定义了更高层次的意图和更低层次的期望，但从可修改性和可移植性的角度来看，没有什么比这更能使分层体系结构具有吸引力。这就是为什么我们要讨论所有层中的接口，它们只是一种抽象机制

---

现在总结一下：如果您的DTO位于服务层，那么它们应该是同一层（或在某些情况下是上面的层）契约的一部分，而不是下面的契约，以便排除层之间的向上依赖关系。接口对于域层以及任何其他抽象层仍然有效（甚至是理想的）。

如果DTO像通常一样用于多个层。然后介绍一个包含所有DTO类型的项目，并让所有其他项目/层引用它。接口可以无处不在，问题只是它们的用途。如果一个接口有一个DTO作为其合同的一部分，那么它应该与DTO在同一层中声明，但域层可能有自己的接口来从实现、单元测试等中抽象出来。谢谢@DmytroMukalov。如果你想回答这个问题，我会接受的。