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

Question

聚合必须设计成事务式的，最终是一致的。实体周围的一致性边界有助于管理复杂性。

在我们的存储库实现中，我们使用实体框架与实际数据库进行接口。历史上，我们总是有大量的上下文(跨越几十个表)，它们代表了数据库中的每个可用的表、字段和关系(或者至少在数据库的某些功能领域)。这里的问题是，这个上下文被用于数百个不同的事物，并且随着系统变得越来越大而成倍增长，从而导致一些很难维护的东西。

有界上下文除法

因此，通常建议为系统中的每个有界上下文创建单独的DbContexts。朱莉·勒曼在她的文章“具有DDD有界上下文的收缩EF模型”中提出了这一点。

除以合计

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

而不是杂乱无章(满足每个人的需要)，它会给上下文明确的意图。

• 当聚合需要更改时，上下文将永远只需要更改。它随着总量的变化而进化。在更大的背景下，系统的许多部分可能取决于上下文的一个部分。一个单一的变化可能会危及很多。
• 只有聚合所需的表、字段和关系才需要存在于上下文中。通常，在处理更大的上下文时，您不会对给定表上的大多数关系或字段感到烦恼。

这种方法也有缺点。即：

• 尽管它们可能会被不同的建模(取决于它们的使用)，但某些数据库表和关系可能需要在多个上下文中存在。
• 如果使用，代码优先迁移将是棘手的。
• 这可能被认为是过度工程.

，有人能提供更多关于这种方法的见解吗？，是不是有什么东西我忽略了？

编辑：

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

Answer 1

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

另一方面，如果您确实知道原子DbContexts是性能瓶颈的话，我可以理解它的原因。

不过，有一件事: EF上下文不需要精确地映射到域层有界的上下文。如果他们这样做了，你试图缩小你的上下文尽可能在双方，它可能造成损害的领域层，海事组织。在这个过程中，域BC可能会失去连贯性，重要的无处不在的语言概念和细分的语义也会丢失。

Answer 2

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

如果底层表和EF上下文是巨大的，我认为这将表明有界上下文可以进一步分解？

我在EF中找到的一个有用的链接是这样的:当我开始使用非常复杂的EF模式时，我尝试了不同的技巧，但最终把它们换成了EventSourcing存储库，但是只有在投影和基础设施的痛苦值得远离迁移、表耦合等的情况下才会这样做。

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

我的建议是，通过保持较小的有界上下文，而不是在有界上下文之间共享EF上下文/数据库，从而保持一切正常和可管理。

您可能会发现，当有界上下文被重新分解和拆分时，您可以将某些部分建模为直接到EntiyFramework的纯CRUD访问，使用EF简单地作为ORM直接指向POCOs，然后再输出到您的应用层。

Answer 3

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

在我看来，这是个非常糟糕的主意。让我给你一些见解。

在领域驱动设计中，您有两种工具:战略工具和战术工具。您不应该分割基于任意策略解决方案的模型。

Bounded Context是一种战略工具。这提供了一个建模边界，可以在其中创建的解决方案--特定的业务问题域。在单个有界上下文中，有一个由团队制定的Ubiquitous Language。团队可以使用任意数量的战术建模工具，例如Aggregates、Entities和Values Objects。

因此，在应用DDD时的最大值在有界上下文的正确定义中。这不仅仅是理论上的产物。除以聚合只会导致混乱和混乱。您将无法清楚地知道您正在解决的是哪种域问题。

另一方面，您只能使用诸如Aggregates、Entities和Values Objects之类的战术模式，但这不是领域驱动的设计。

而不是乱(满足每个人的需要)，它会给上下文明确的意图.

怎么做到的？我搞不懂。对我来说，这会造成更多的混乱。有限制的上下文集成是通过Anti corruption layers完成的，这可以保护您免受外部变化的影响。有限制的上下文可以独立于其他上下文发展。如果您想从战略的角度更多地了解有界上下文之间的集成是如何发生的，请查看Context mapping。

尽管它们可能会被不同的建模(取决于它们的使用)，但某些数据库表和关系可能需要在多个上下文中存在。如果使用，代码优先迁移将是棘手的。这可能被认为是过度工程.

在进行领域驱动设计时，您不会基于技术限制来驱动您的选择，特别是ORM框架。

更进一步：

聚合有时可以具有有界上下文的1:1映射。但这实际上取决于业务问题，而不是技术解决方案。

如果没有更深入的理解，领域驱动的设计是不容易应用的。有时候，您的域并不真正需要它，所以没有必要试图将它强加给您的特定问题。

最后，我将坚持朱莉·勒曼文章中提出的观点。