关于 DDD 结构和分层。

Question

各位， 抱歉，如果这已在另一个线程中涉及，但我搜索了 ddd 和 mvc 文章并没有找到一个简单的答案。

我希望将 DDD 方法应用于我的 MVC 项目的架构。请纠正我的错误。

所有涉及命中域模型的 MVC 控制器操作最初都会命中 和应用服务层。 此处的应用程序服务层充当表示和域之间的门面。 稍后来自应用程序服务的任何明显涉及离散域聚合的请求都将使用存储库对聚合根执行获取或修改操作。每个聚合根都有自己的存储库。

因此应用服务层必须注入域所需的任何/所有存储库。

如果一项操作可能涉及多个聚合或需要的逻辑不能完全适合一个聚合，则应用程序服务将调用域服务来跨聚合执行操作。

这对我来说似乎不对。 我的困惑是，从 DDD 的角度来看，我不确定例如聚合根是否应该执行自己的持久性，即聚合被注入存储库，然后自身持久化/获取，或者应用程序服务层是否使用存储库来操作或获取聚合？

另外如果应用服务层注入了所有的repositories，那么应用服务层调用的领域服务是否也需要注入repositories？

目前我将 CQRS 排除在外。我想首先理清服务和聚合之间的分层和关系。

感谢您的建议。

Answer 1

所有涉及到域模型的 MVC 控制器操作都会 最初命中和应用服务层。这里的应用服务层充当表示和领域之间的门面。

对此存在争议，但我会仔细考虑是否需要额外的层。它添加了许多样板代码并降低了可维护性 - 作为某人pointed out recently，当您将出于相同原因而更改的事物（即您的服务方法和相应的域方法）分开时，您必须在许多不同的地方进行更改系统。

另一方面，您可能需要该服务层将您的域对象映射到 DTO，但同样，它可以直接在 Controller 中完成，没有什么可以强迫您to use DTOs in the presentation layer。

我的困惑是，从 DDD 的角度来看，我不确定是否为 示例聚合根应该执行它们自己的持久性，即 聚合被注入存储库，然后持久化/获取 本身还是如上应用服务层使用 要操作或获取聚合的存储库？

让聚合根管理自己的持久性通常被认为是不好的做法，因为它打破了对持久性的无知并违反了单一职责原则。如果你这样做了，你的聚合根类现在有 2 个改变的理由，2 个破坏代码的理由，它更不容易维护，等等。

您应该将在其存储库中保存聚合根目录的责任委托给能够感知应用程序执行上下文的对象（例如，控制器或应用程序层中的对象）。

如果应用服务层注入了所有 repositories，做应用服务的领域服务 层调用也需要注入仓库？

是的，我认为这很有意义，尤其是在域服务严重依赖存储库的情况下。