必须将聚合设计为事务性的并最终保持一致性.实体的这种一致性边界有助于管理复杂性
在我们的存储库实现中,我们使用Entity Framework与实际数据库进行交互.从历史上看,我们总是拥有巨大的上下文(跨越数十个表),它们代表数据库中的每个可用表,字段和关系(或至少在数据库的某些功能区域中).这里的问题是,这个上下文用于数百种不同的事情,并随着系统变大而呈指数级增长,从而导致难以维护的事物.
有界背景划分
因此,通常建议应为系统中的每个有界上下文创建单独的DbContexts. Julie Lerman在她的文章Shrink EF Models with DDD Bounded Contexts中提出了这一点.
按总部划分
如果我们的聚合在事务上是一致的,那么是什么阻止我们更进一步并创建专用上下文来为每个聚合存储库提供服务？
它不是滥交(服务于每个人的需要),而是给出了明确的意图.
>当聚合需要改变时,上下文只需要改变.它随着聚合而演变.对于更大的上下文,系统的许多部分可能依赖于上下文的一部分.一次改变可能会危及很多.
>只有聚合所需的表,字段和关系才需要存在于上下文中.通常在处理更大的上下文时,您不会对给定表上的大多数关系或字段感到困扰.
这种方法存在缺点.即：
>虽然它们可能会以不同的方式建模(取决于它们的用途),但某些数据库表和关系可能需要存在于多个上下文中.
>如果使用,代码优先迁移将是棘手的.
>这可能被视为过度工程.
任何人都可以提供有关此方法的任何见解吗？是否有一些我忽略的东西？
编辑：
请注意,我们未在域中使用EF数据实体.我们的存储库从这些数据实体中实例化并融合了更丰富的域模型.
