民间， 如果这已经被另一个帖子所覆盖，我很抱歉，但是我搜索了ddd和mvc的文章并没有找到一个简单的答案。
我希望将DDD方法应用于我的MVC项目的架构。请纠正我错在哪里。
所有涉及击中域模型的MVC控制器操作最初都会被触发 和应用服务层。 此处的应用程序服务层充当表示和域之间的外观。 稍后来自应用程序服务的任何明确涉及离散域聚合的请求将使用存储库对聚合根执行获取或修改操作。每个聚合根目录都有自己的存储库。
因此必须向应用程序服务层注入域所需的任何/所有存储库。
如果某个操作可能涉及多个聚合或要求逻辑不能完全适合一个聚合，则应用程序服务将调用域服务以跨聚合执行操作。
这对我来说似乎不对。 我的困惑是，从DDD的角度来看，我不确定例如聚合根是否应该执行它们自己的持久性，即聚合被注入存储库然后持久化/获取自身，或者是否如上所述应用服务层使用存储库来执行或获取聚集体
此外，如果应用程序服务层注入了所有存储库，那么应用程序服务层调用的域服务是否也需要注入存储库？
此时我将CQRS排除在外。我希望首先将分层和服务与聚合之间的关系整理出来。
感谢您的任何建议。
答案 0 :(得分：2)
涉及击中域模型的所有MVC控制器操作都将 最初命中和应用服务层。这里的应用程序服务层充当表示和域之间的外观。
对此有争议，但我会仔细考虑是否需要额外的图层。它添加了大量的样板代码并降低了可维护性 - 作为某人pointed out recently，当您因为相同的原因（即您的服务方法和相应的域方法）分离更改的内容时，您必须在许多不同的地方进行更改在系统中。
另一方面，您可能需要该服务层将您的域对象映射到DTO，但又一次，它可以直接在Controller中完成，并且没有任何东西迫使您to use DTOs in the presentation layer。
我的困惑是，从DDD的角度来看，我不确定是否适合 例如聚合根应该执行它们自己的持久性，即 使用存储库注入聚合，然后保持/提取 本身或是否与应用程序服务层使用的相同 处理或获取聚合的存储库？
通常认为让聚合根管理自己的持久性是不好的做法，因为它打破了持久性无知并违反了单一责任原则。如果你这样做，你的聚合根类现在有两个改变的理由，2个破坏代码的原因，它不太可维护等等。
您应该将在其存储库中保存聚合根的责任委派给将知道应用程序执行上下文的对象（例如，Controller或Application层中的对象）。
此外，如果应用程序服务层全部注入 存储库，是应用程序服务的域服务 层调用还需要注入存储库吗？
是的，我认为这非常有意义，特别是如果域服务严重依赖于存储库。