DDD、CQRS、洋葱架构、企业级应用的ef core答案

【问题标题】：DDD, CQRS, onion architecture, ef core for enterprise level appDDD、CQRS、洋葱架构、企业级应用的ef core
【发布时间】：2020-01-21 06:13:21
【问题描述】：

最近我发现以下方法对我从事的许多项目都很有效。然而问题是，我读到 ef core DbContext 本身就是一个 UoW，我不应该创建自己的 UoW 和存储库。但在这种情况下，我无法从我的应用程序逻辑层中抽象出我的持久层。

TL；DR 问题是： 是否可以不拥有自己的存储库或拥有 UoW，并且仍然遵循提到的架构，将 DbContext 作为 UoW？

我的架构如下：

第 1 层（最内层）：聚合、实体、POCO 域类、值对象

第 2 层： 域服务

第 3 层： 应用程序服务（CQRS 命令、查询、处理程序）和存储库接口

4A 层：（持久层）存储库实现（此处注入 DbContext） EF Core 映射（ORM 映射）

第 4B 层： Asp MVC API（DI在这里注册）

API 的控制器只是发出命令和查询（通过 MediatR）。

上述方法的优点是应用程序核心（第 1、2 和 3 层）完全从持久性中抽象出来。缺点是你真的要自己写Repositories。

这是正确的方法吗？还是我错过了什么？

【问题讨论】：

这个问题很宽泛且基于观点，它不适合 Stack Overflow。此外，它还引发了一场在其他网络资源中已有充分报道的旧辩论。

标签： entity-framework domain-driven-design cqrs onion-architecture

【解决方案1】：

为什么 DbContext 是一个工作单元？

DbContext 通过一次提交 (SaveChanges) 捕获您在一个事务中所做的所有更改。

为什么不创建自己的？

理想情况下，您应该只通过一个事务提交一个数据存储。如果您在多个事务中保存到多个数据存储，或者在多个事务中保存到同一个数据存储，那么您可能面临数据损坏的可能性。如果您使用跨多个数据存储的分布式事务，那么上帝会帮助您。

因此，SaveChanges 应该就足够了，那么为什么要创建自己的呢？

那么抽象呢？

如果 SaveChanges 就足够了，那么我们如何抽象出对 EF 的依赖呢？您可以使用单个方法 Commit 引入 IUnitOfWork 接口，您可以通过调用 DbContext.SaveChanges 来实现该方法。

还有存储库？

我不确定我是否理解不将创建存储库作为一项硬性规则。作为抽象出持久层的一部分，有一个像 IRepository 这样的层来提供这种分离是很有帮助的。也就是说，您不应该为每个表创建一个存储库。每个聚合一个存储库更合适。每个存储库都会加载整个 Aggregate，以确保 Aggregate 边界内的一致性。

...

一般而言，如果您不了解该建议背后的原因，我会告诫不要听从绝对的建议。给自己相同的起始信息，您应该能够得出相同的结论。否则，您只是将死记硬背应用于并非总能从该方法中受益的模式。

【讨论】：