我一直在寻找在域驱动设计中使用IoC容器的指导。不幸的是，埃文的书没有触及这个主题。我在互联网上找到的唯一重要指导原则是here。
马洛维奇的许多观点都是常识，但我很担心其中的一些。他建议IoC容器应保留用于仅解析服务，并且使用IoC容器来解析域依赖性是一个坏主意。但是，他没有用任何例子来支持这个断言。他简单地说它是事实。
然后，他继续说混合IoC容器和工厂是没有意义的。这似乎与他的第一点相矛盾。事实上，如果IoC容器不能解析域依赖关系，那么它们应该如何解决呢？埃文的书清楚地指出工厂是合乎逻辑的选择。我很感激您对此事的任何意见。对于DDD和IoC，我都是新手。我很难掌握IoC和DDD如何协同工作。
答案 0 :(得分：3)
在我看来，他在域模型中不使用IoC容器是正确的。这种做法我也跟着自己。基本思想是服务可能包含基础结构依赖性，因此模仿它们是明智的。域实体没有那些，所以模拟它们并不重要（仍然编码接口是很好的做法）。
域实体的工厂不应该在IoC容器中，但服务工厂应该。基本上，您可以在您的服务中引用实体工厂。这不是很紧密的耦合。
关于IoC的好读物可以在Billy McCafferty's blog post "Dependency Injection 101"
找到答案 1 :(得分：0)
在设计可单元测试的代码并且与DDD正交时，IOC容器非常有用。如果你想要，你可以创建自己的工厂和构建器模式实现...为什么要经历麻烦？
绝对。使用足够强大的IOC容器来满足您的特定要求;不多也不少。
答案 2 :(得分：-1)
我们使用DDD和依赖注入（模式），但不使用依赖注入框架。
流行的依赖注入框架的一个问题是它们如何将配置分离为XML文件。 XML是一种很棒的标记语言。如何成为一种配置语言，我永远不会理解。当然，问题是您必须在知道所有内容是否正确连接之前运行该应用程序。很难看出在哪里使用了什么代码。如果您正在使用接口，那么对实现的唯一引用将位于XML文件中，这很难发现。最后，你失去了类型安全和泛型。 （我曾经在生产中看到过一个可怕的错误，如果我们没有使用XML，编译器就会抓到它。）
我应该指出，我并不是说依赖注入是坏事。它是良好对象设计的基本模式。但在工厂进行布线绝对没有错。
在我的最后两个项目中，我们已经从XML文件和工厂中删除了大量“代码”。工厂与容器管理服务（例如JDBC连接，JMS连接等）连接在一起。应用程序变得更加容易理解，因为工厂比XML更简洁。作为一名Java程序员，使用控制空间而不是XML twiddling将程序连接起来要容易得多 - 而且当你破坏某些东西时，你的IDE会突出显示。
在集成测试中，只需像在工厂中一样创建对象。
即
dbConnection = DatabaseConnectionFactory.connection();
serviceUnderTest = new PaymentProcessor(new CustomerRepository(connection));