Model view controller 关于DDD结构和分层。

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

我希望将DDD方法应用到我的MVC项目的体系结构中。请纠正我哪里错了

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

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

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

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

另外，如果应用程序服务层与所有存储库一起注入，那么应用程序服务层调用的域服务是否也需要注入存储库

在这一点上，我不让CQR参与进来。我想首先理清分层以及服务和聚合之间的关系

谢谢你的建议

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

有争议，但我会仔细考虑是否需要额外的层。它添加了大量样板代码并降低了可维护性—作为一个人，当您将由于相同原因（即您的服务方法和相应的域方法）而更改的内容分开时，您必须在系统中的许多不同位置进行更改

另一方面，您可能需要该服务层将您的域对象映射到DTO，但同样地，它可以直接在控制器中完成，并且没有任何强制要求

我的困惑是，从DDD的角度来看，我不确定是否 示例聚合根应执行其自身的持久性，即 聚合被注入存储库，然后持久化/获取 自身或应用程序服务层是否使用 要对其进行操作或获取聚合的存储库

让聚合根管理自己的持久性通常被认为是不好的做法，因为它打破了对持久性的无知，违反了单一责任原则。如果这样做，聚合根类现在有两个原因需要更改，两个原因需要中断代码，它的可维护性较差，等等

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

如果应用程序服务层注入了所有 存储库，应用程序服务所在的域服务 层调用也需要注入存储库

---

是的，我认为这非常有意义，尤其是当域服务严重依赖于存储库时。

因此，我不应该为应用程序服务层而烦恼，而应该将存储库注入控制器。然后通过存储库控制器获取和修改域对象？我关心的是，现在控制器中发生了很多事情。“控制器接收用户输入并通过调用模型对象来启动响应”（来自维基百科的定义）。现在，如果您认为控制器将承担太多的责任，那么您需要引入一个附加层。此外，Mark Seemann最近发表了一篇博文，强调了更多层次的额外工作，并质疑了在各种情况下拥有大量层次的相关性：