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

【问题标题】：Domain Driven Design: Can Infrastructure or Repositories use Domain objects?领域驱动设计：基础设施或存储库可以使用领域对象吗？
【发布时间】：2016-03-10 22:00:01
【问题描述】：

考虑到领域驱动设计，Infrastructure 或 System 是否可以使用 Domain 的对象（值、实体等），还是应该应用 Dependency Inversion，使 Infrastructure 只依赖于自己定义的 Interfaces？

存储库呢？是否同样适用？

是否违反了基础设施、存储库或系统代码取决于域？

(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) { ... }
    }
}

【问题讨论】：

标签： domain-driven-design

【解决方案1】：

一般来说，如果您的基础架构依赖于您的域，我会说没关系。反过来也不是什么好主意。

这样想：什么更可能在某个时候被替换？基础设施还是领域？

基础设施会随着时间而改变（不同的提供商、不同的服务器……）另一方面，您的域将永远存在

【讨论】：

如果您在设计时考虑到基础架构可以依赖（以using 关键字的方式）域，您如何避免循环依赖？因为域将使用依赖于域的基础设施服务。
嗯，域应该依赖于基础设施的接口，而不是基础设施本身。例如，域定义了它需要的接口，然后你为该接口提供一个实现
Domain 会声明它需要的服务接口，然后 Infrastructure、Repositories 等会实现它？现在这对我来说很有意义。您选择此类接口实现的方法是什么？依赖注入？将实现传递给构造函数？全局配置上下文？
依赖注入。 onion architecture 更详细地解释了这种方法。
@FelipeLavratti 我很难理解使用 DI 或将实现传递给构造函数是什么意思。我想你可能在想一些 Not So Nice 所以如果你分享一些代码会很好。通常，您的域在任何意义上都不需要对基础设施一无所知，甚至不需要自己的接口和构造函数注入。例如，存储库知道如何持久化您的实体，但实体对存储库和持久性一无所知。