entity-framework - 如何聚合存储库？

Question

我正在为一家电信公司开发一个大型系统。我是 DDD 的新手，很难将不同的部分链接在一起。我们当前的系统是使用 NHibernate 构建的。它目前有超过 600 个表，所有数据访问都是使用 NHibernate 完成的，但对于新系统，我们将使用 EF。下面是几个功能区和各个功能区的数据库表示例。

客户
-----> 客户统计
-----> 客户付款
-----> 客户交易

路由引擎
-----> 入站路由
-----> OutboundRoutes

供应引擎
-----> InboundSwithces
-----> OutboundSwitches
-----> 路由器配置
-----> 网关配置

计费引擎
-----> 入站流量
-----> 出站流量

由于系统必须是可单元测试的，我开始使用存储库模式抽象实际实体。一种方法是为每个数据库表创建一个存储库对象。当然，所有这些存储库类都可以从通用存储库接口(interface)派生。然而，这将在代码库维护方面增加相当多的开销。在 DDD 中，我读到了聚合的这个概念，但我不确定它应该如何专门应用于 EF 的上下文中。 Aggregate 对象应该是这些存储库的容器，还是这些更多是相关上下文的容器(意思是类似于 Bounded DbContexts)？

Answer 1

One approach is to create one repository object for each each database table.

在 DDD 中，由于忽略了持久性的概念，数据库表通常不会与存储库进行一对一的映射。相反，存储库应该与聚合是一对一的。

Of course all these repository classes could be derived from a generic repository interface.

存储库模式可能是一个滑坡。虽然它非常适合封装，但很容易被不必要的抽象带走。看看here换个角度看。

Should the Aggregate objects are container of these repositories or are these more of a container of related contexts (meaning something along the lines of Bounded DbContexts)?

您所说的“功能区”似乎被称为bounded contexts。 (BC) 在 DDD 中。 (不是 EF 中的 DbContext)。此外，聚合不是存储库的容器，它们包含一组来自您的域模型的相关实体。典型示例是销售订单模型，其中您有一个订单聚合，该订单聚合由订单聚合根和各种实体和值对象(例如订单行项目)组成。如上所述，聚合是存储库应提供访问的域对象。因此，您应该围绕聚合构建存储库，但当然首先您必须确定聚合和 BC。看看Effective Aggregate Design by Vaughn Vernon .

此外，在单个 BC 中拥有 600 张 table 似乎太多了，这可能表明您有多个 BC 在起作用。 BC 实现的是 functional cohesion ，这反过来又是对您的存储库进行分组(“聚合”与 DDD 术语冲突)的最合适方式。