domain-driven-design - 聚合、事务一致性和 Entity Framework DbContext

Question

聚合必须被设计成事务性和最终一致性。这种围绕实体的一致性边界有助于管理复杂性。

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

按有界上下文划分

因此，通常建议应为系统中的每个有界上下文创建单独的 DbContext。 Julie Lerman 在她的文章中提出了这一点，Shrink EF Models with DDD Bounded Contexts .

按总量划分

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

它不会混杂(满足每个人的需求)，而是提供上下文 意图明确 .

只有当聚合需要更改时，上下文才需要更改。它随着聚合而发展。对于更大的上下文，系统的许多部分可能依赖于上下文的一部分。一次更改可能会危及很多。

只有聚合所需的表、字段和关系需要存在于上下文中。通常在处理更大的上下文时，您不会为给定表上的大多数关系或字段而烦恼。

这种方法有缺点。即:

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

如果使用，代码优先迁移将是棘手的。

这可以被认为是过度设计。

任何人都可以提供有关这种方法的进一步见解吗？ 也许我忽略了一些东西？

编辑:

请注意，我们没有在我们的域中使用 EF 数据实体。我们的存储库从这些数据实体中实例化和水化一个更丰富的域模型。

Answer 1

我不认为多聚合上下文是一个问题，特别是如果你遵循严格的聚合分离——没有对聚合之外的实体的引用，只有键到根的松散引用。

另一方面，如果您确定它是性能瓶颈，我可以理解为什么您会想要原子 DbContexts。

不过有一件事:EF 上下文不必完全映射到域层有界上下文。如果他们这样做并且您尝试在两侧尽可能地缩小您的上下文，则可能会在域层 IMO 中造成损坏。域 BC 可能会失去其连贯性，并且重要的普遍存在的语言概念和分割的语义可能会在此过程中丢失。