聚合,事务一致性和实体框架DbContext

Question

必须将聚合设计为事务性的并最终保持一致性.实体的这种一致性边界有助于管理复杂性

在我们的存储库实现中,我们使用Entity Framework与实际数据库进行交互.从历史上看,我们总是拥有巨大的上下文(跨越数十个表),它们代表数据库中的每个可用表,字段和关系(或者至少在数据库的某个功能区域中).这里的问题是,这个上下文用于数百种不同的事物,并随着系统变大而呈指数级增长,从而导致难以维护的事物.

有界背景划分

因此,通常建议应为系统中的每个有界上下文创建单独的DbContexts.Julie Lerman在她的文章" 缩小具有DDD有界上下文的EF模型"中提出了这一点.

按总部划分

如果我们的聚合在事务上是一致的,那么是什么阻止我们更进一步并创建专用上下文来为每个聚合存储库提供服务？

它不是滥交(服务于每个人的需要),而是给出了明确的意图.

• 当聚合需要改变时,上下文只需要改变.它随着聚合而演变.对于更大的上下文,系统的许多部分可能依赖于上下文的一部分.一次改变可能会危及很多.

• 只需要在上下文中存在聚合所需的表,字段和关系.通常在处理更大的上下文时,您不会对给定表上的大多数关系或字段感到困扰.

这种方法有缺点.即:

• 虽然它们可能会以不同的方式建模(取决于它们的用途),但某些数据库表和关系可能需要存在于多个上下文中.

• 如果使用,代码优先迁移将是棘手的.

• 这可能被视为过度工程.

任何人都可以提供有关此方法的任何见解吗？是否有一些我忽略的东西？

编辑:

请注意,我们未在域中使用EF数据实体.我们的存储库从这些数据实体中实例化并融合了更丰富的域模型.

Answer 1

好问题 - 如果您使用 EF 作为 CRUD 访问来实现存储库，然后在顶部丰富的 DDD 实体上分层，那么您的有界上下文不会决定用于保存其中包含的所有实体的底层数据库模式的大小吗？

如果基础表和 EF 上下文很大，我认为这表明有界上下文可以进一步分解？

我发现 EF 的有用链接如下：http ://mehdi.me/ambient-dbcontext-in-ef6/当我开始拥有非常复杂的 EF 架构时，我尝试了不同的技巧，但最终将它们换成了 EventSourcing 存储库，但只是值得摆脱迁移、表耦合等投影和基础设施的痛苦。

最终，如果建模的有界上下文的大小正确，那么即使所有 DbSet 都包含在同一个 DbContext 中，复杂性仍然是可控的。

我的建议是坚持使用较小的有界上下文，而不是在有界上下文之间共享 EF 上下文/数据库，从而使一切保持理智且易于管理。

您可能会发现，随着有界上下文被重构和拆分，您可以将某些部分建模为直接对 EntiyFramework 的纯 CRUD 访问，使用 EF 简单地作为直接到 POCO 的 ORM，然后再到您的应用程序层。