设计模式：工厂和仓储。

Question

我一直在想，工厂模式和仓储模式是否适合在领域驱动设计项目中配合使用？

我这样做的原因是：

GUI -> ClassFactory -> ClassProduct（在领域模型中） -> ClassProductRepository -> 数据源

GUI 调用 ClassFactory 以将 GUI 与业务逻辑分离。ClassProduct 调用 ClassProductRepository 以将业务逻辑与数据源分离。

这种在领域驱动设计中使用设计模式的方法是否不正确？如果是，请陈述您对此问题的观点。

- Poku

Answer 1

你走在正确的路上。正如Chad指出的那样，你需要使用GUI界面分离模式作为你的领域和UI之间的附加层。MVC、MVP、Presentation Model等都是已经建立且有文档记录的UI分离模式。Martin Fowler优秀的PoEAA一书涵盖了其中许多模式。

至于你的主要问题。是的。工厂和仓库非常适合搭配使用。事实上，Evans在DDD中建议，在某些情况下，当你从数据存储重构对象时，可以将对象创建的责任委托给工厂类而不是仓库。

client <=> repository -> factory
               |
               v
            database

1. 客户端从仓库请求一个对象。
2. 仓库查询数据库。
3. 仓库将原始数据发送给工厂。
4. 工厂返回对象。

这只是一个过于简单化的解释，但你应该可以理解。Evans没有提到的一点（但Fowler有涉及）是依赖注入。随着您的领域复杂性的不断增长，您可能需要考虑使用IoC容器来管理对象生命周期。

- Kenneth Cochran

Answer 2

我建议您坚持使用MVC作为通用方法来分离业务逻辑、视图和控制器。这是一个经过充分记录和研究的方法，尽管它是目前最好的方法。

然而，看起来你只是想使用这种模式而已。这对于学习很好，但在大多数应用系统中，我看到你描述的模式要么不存在，要么简单的方法更有效，要么维护起来是一场噩梦。

请参见我之前回答类似问题的答案，其中包含一个视频，可以帮助您在未来的设计中。
链接

- Chad

---

我不是为了使用而使用它。我希望我的系统低耦合，这样我就能得到一个易于维护的系统。我知道MVC可以帮助我实现这个目标，但我也希望模型层低耦合。因此，以主题中的示例为例，我们可以将GUI与我想要从模型层使用的任何类交换。这种方法是否会将我对低耦合的愿望推向极端？ - Poku

在“模型”内部，您可以使用状态模式来实现自己的模型，这可以随时替换。虽然如果您可以逻辑上将您的模型与视图分离，那么您已经领先了大部分时间。 - Chad