使用DDD有界上下文的实体配置管理

Bre*_*tin 5 c# domain-driven-design entity-framework

我正在尝试实现这里概述的多个DDD有界上下文.这是一个示例上下文:

示例上下文

我有一个实体类型配置文件,每个实体都有适当的FluentAPI映射(使用EF工具进行逆向工程).这些配置文件还包括关系配置.

例如:UserMap.cs

// Relationships
this.HasOptional(t => t.SecurityProfile)
    .WithMany(t => t.Users)
    .HasForeignKey(t => t.SecurityProfileCode);
Run Code Online (Sandbox Code Playgroud)

SecurityProfileDomainPermission不是DbSets在上下文中.由于导航属性UserModule分别导致它们自动进入模型.

这导致我的第一个问题.将User(或任何其他实体)添加到任何其他上下文时,我必须记住做以下两件事之一:

  1. 还要将配置添加到模型构建器SecurityProfile(以及实体上的每个其他关系)

  2. SecurityProfile不知何故明确地从模型中排除.

这开始变成一个维护噩梦.

我很满意明确地"修剪"实体图,如上面第2点所述.

但是,Ignore()当实体配置文件中已经定义了关系时,实体似乎不可能.

尝试modelBuilder.Ignore<SecurityProfile>();上述上下文OnModelCreating会出现以下错误ConfigureAssociations():

System.InvalidOperationException:导航属性"SecurityProfile"不是"User"类型的声明属性.验证它是否未从模型中明确排除,并且它是有效的导航属性.

我能想到的唯一解决方案是继承基本配置类并覆盖每个上下文中的关系配置.考虑到我们最终可能会有30-40个单独的背景,这也可能成为维护的噩梦.

或者,我可以为每个上下文设置非常具体的实体模型,但这又会导致实体类爆炸以及重复配置中的潜在维护问题.

在实现有界上下文时,如何才能最好地管理和维护实体及其实体配置?

Ale*_*lex 1

由于评论有点太长,添加到这里:

非常(不?)有趣的是,您所引用的文章显然是试图通过提到一个新的流行语来赶上潮流DDD,然后仅显示 DTO/POCO 对象如何在上下文中持久化。这和DDD完全没有关系。

领域驱动设计主要涉及行为和封装(基础设施隔离/无知)模型,这些模型经过迭代探索和细化,以解决特定参与者的特定问题,并在ubiquitous language问题域中表达。

这些模型通常不直接映射到某种类型的持久性模型,也不应该关心这一点。在有界上下文内的聚合根上执行的操作通常将与事务边界对齐。

我建议您观看 Eric Evan 的一些有关 SkillsMatter(关键字 DDD eXchange)的网络广播,以便正确了解 DDD 的含义、有界上下文和聚合根是什么。之后你也真的应该读他的书,这是一本很棒的书。但您需要他最新的观点(如这些网络广播中所表达的),而不是陷入专注于技术构建模块的陷阱。