IoC 容器和领域驱动设计

Question

我一直在寻找在域驱动设计中使用 IoC 容器的指南。不幸的是，埃文的书没有涉及这个主题。我可以在互联网上找到的唯一实质性指南是 here。

马洛维奇的许多观点都是常识，但我担心其中的一些观点。他建议应保留 IoC 容器仅用于解析服务，并且使用 IoC 容器来解决域依赖关系是一个坏主意。然而，他没有用任何例子来支持这一断言。他简单地陈述了事实。

他接着说，混合 IoC 容器和工厂是没有意义的。这似乎与他的第一点相矛盾。事实上，如果域依赖不应该由 IoC 容器解决，那么应该如何解决它们呢？ Evan 的书明确指出工厂是合乎逻辑的选择。

如果您对此事有任何意见，我将不胜感激。在 DDD 和 IoC 方面，我都是新手。我正在努力理解 IoC 和 DDD 如何协同工作。

Answer 1

在我看来，他在域模型中不使用 IoC 容器是正确的。我自己也遵循这种做法。基本思想是服务可能包含基础设施依赖项，因此模拟它们是明智的。域实体没有这些，因此模拟它们并不重要（仍然对接口进行编码是一种很好的做法）。

域实体的工厂不应该在 IoC 容器中，但服务的工厂应该。基本上你可以在你的服务中引用实体工厂。这不是很紧密的耦合。

可以在Billy McCafferty's blog post "Dependency Injection 101" 找到有关 IoC 的好读物

Answer 2

IOC 容器在设计可单元测试的代码时非常宝贵，并且与 DDD 正交。如果您愿意，您可以创建自己的工厂和构建器模式实现...为什么要经历这些麻烦？

当然。使用足够强大的 IOC 容器来满足您的特定要求；不多不少。

Answer 3

我们使用 DDD 和依赖注入（模式），但不使用依赖注入框架。

流行的依赖注入框架的一个问题是它们如何将配置分离到 XML 文件中。 XML 是一种很棒的标记语言。它是如何成为一种配置语言的，我永远不会明白。当然，问题是您必须先运行应用程序，然后才能知道一切是否正确连接。也很难看出在哪里使用了哪些代码。如果您使用接口，那么对实现的唯一引用将在 XML 文件中，这很难发现。最后你失去了类型安全和泛型。 （我曾经在生产中看到一个可怕的错误，如果我们不使用 XML，编译器会发现它。）

我应该指出，我并不是说依赖注入不好。它是良好对象设计的基本模式。但是在工厂里做接线绝对没有错。

在我最近的两个项目中，我们已经从 XML 文件中删除了大量“代码”，并进入了工厂。这些工厂与容器管理的服务（例如 JDBC 连接、JMS 连接等）连接起来。应用程序变得更易于理解，因为工厂比 XML 更简洁。作为一名 Java 程序员，使用控制空间将程序连接在一起要容易得多，而不是 XML 玩弄——当你破坏某些东西时，你的 IDE 会突出显示。

在集成测试中，只需像在工厂中一样创建对象。

即，

dbConnection = DatabaseConnectionFactory.connection();    
serviceUnderTest = new PaymentProcessor(new CustomerRepository(connection));