领域驱动设计：基础设施或存储库是否可以使用领域对象？

Question

考虑到领域驱动设计，基础设施或系统能否使用领域的对象（值、实体等），或者应该应用依赖倒置，使得基础设施仅依赖于自己定义的接口？

仓库又如何呢？是否适用相同的规则？

如果基础设施、仓库或系统的代码依赖于领域，这算是违反规则吗？

(A) 基础设施依赖于领域的示例代码：

namespace Infrastrcuture {
    public class Sender {
        public void Send (Domain.DataValue data) { ... }
    }
}

(B) 一个基础设施不依赖于域的示例代码：

namespace Infrastrcuture {
    public interface ISendableData {
        ...
    }
    public class Sender {
        public void Send (ISendableData data) { ... }
    }
}

- Felipe Lavratti

Answer 1

总的来说，如果您的基础架构依赖于您的域名，那么这是可以接受的。相反，反过来则不是一个好主意。

这样想一下：在某个时间点上，什么更有可能被替换？基础架构还是域名？

基础架构会随着时间的推移而改变（不同的提供商，不同的服务器，...）而您的域名将永远存在。

- Kenneth

---

如果您在设计时考虑基础架构可以依赖于领域（使用 using 关键字），那么如何避免循环依赖？因为领域将使用基础架构的服务，而这些服务又依赖于领域。 - Felipe Lavratti

领域应该依赖于基础设施的接口，而不是基础设施本身。也就是说，领域定义了它需要的接口，然后您为该接口提供实现。 - Kenneth

那么，Domain 将声明其所需服务的接口，然后 Infrastructure、Repositories 等将对其进行实现？现在我明白了。您选择实现此类接口的方法是什么？依赖注入？将实现传递给构造函数？全局配置上下文？ - Felipe Lavratti

依赖注入。洋葱架构详细解释了这种方法。 - Adam Siemion

@FelipeLavratti 我很难理解你所说的使用 DI 或将实现传递给构造函数的含义。我认为你可能在考虑一些“不太好”的东西，如果你能分享一些代码就更好了。通常情况下，你的领域不需要以任何方式了解基础设施，甚至不需要通过自己的接口和构造函数注入。例如，存储库知道如何持久化你的实体，但实体对存储库和持久化一无所知。 - Alexey Zimarev