域驱动设计 – 聚合,事务一致性和实体框架DbContext

前端之家收集整理的这篇文章主要介绍了域驱动设计 – 聚合,事务一致性和实体框架DbContext前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
必须将聚合设计为事务性的并最终保持一致性.实体的这种一致性边界有助于管理复杂性

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

有界背景划分

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

按总部划分

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

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

>当聚合需要改变时,上下文只需要改变.它随着聚合而演变.对于更大的上下文,系统的许多部分可能依赖于上下文的一部分.一次改变可能会危及很多.
>只有聚合所需的表,字段和关系才需要存在于上下文中.通常在处理更大的上下文时,您不会对给定表上的大多数关系或字段感到困扰.

这种方法存在缺点.即:

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

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

编辑:

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

我没有看到多聚合上下文是一个问题,特别是如果你遵循严格的聚合分离 – 没有引用聚合之外的实体,只有按键的根到根松散引用.

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

但有一件事:EF上下文不必完全映射到Domain layer Bounded Contexts.如果他们这样做并且您尝试尽可能地缩小双方的上下文,则可能会导致域层IMO受损.域BC可能会失去一致性,重要的无处不在的语言概念和细分的语义可能会在此过程中丢失.

原文链接:https://www.f2er.com/javaschema/282047.html

猜你在找的设计模式相关文章