使用DDD有界上下文的实体配置管理
我正在尝试实现此处概述的多个DDD有界上下文。 这是一个示例上下文：
我有一个实体类型配置文件，每个实体都有适当的FluentAPI映射（使用EF工具进行反向工程）。 这些配置文件还包括关系配置。
例如：UserMap.cs
// Relationships this.HasOptional(t => t.SecurityProfile) .WithMany(t => t.Users) .HasForeignKey(t => t.SecurityProfileCode); SecurityProfile和DomainPermission不是DbSets中的DbSets 。 由于User和Module上的导航属性，它们会自动进入模型。
这导致我的第一个问题。 将User （或任何其他实体）添加到任何其他上下文时，我必须记住执行以下两项操作之一：
-
还要将配置添加到
SecurityProfile的模型构建器（以及实体上的每个其他关系） -
以某种方式明确地从模型中排除
SecurityProfile。
这开始变成一个维护噩梦。
我很满意明确地“修剪”实体图，如上面第2点所述。
但是，当实体配置文件中已经定义了关系时， Ignore()实体似乎不可能。
尝试使用modelBuilder.Ignore(); 对于上面的上下文OnModelCreating在ConfigureAssociations()给出以下错误：
System.InvalidOperationException：导航属性“SecurityProfile”不是“User”类型的声明属性。 validation它是否未从模型中明确排除，并且它是有效的导航属性。
我能想到的唯一解决方案是inheritance基本配置类并覆盖每个上下文中的关系配置。 考虑到我们最终可能会有30-40个单独的背景，这也可能成为维护的噩梦。
或者，我可以为每个上下文设置非常具体的实体模型，但这又会导致实体类爆炸以及重复配置中的潜在维护问题。
在实施有界上下文时，如何才能最好地管理和维护实体及其实体配置？
由于评论有点太长，因此在此处添加：
非常（非？）有趣的是，你所指的文章显然是试图通过提及一个新的流行语DDD并随后仅显示DTO / POCO对象如何在上下文中持久化来加入潮流。 这与DDD绝对无关。
领域驱动设计主要是关于行为和封装（基础设施隔离/无知）模型，这些模型经过迭代探索和改进，以解决特定参与者的特定问题，并以问题域的ubiquitous language表达。
这些模型通常不直接映射到某种类型的持久性模型，也不应该关注它。 在有界上下文中对聚合根执行的操作通常将与事务边界一致。
我建议你观看Eric Evan关于技能人员（关键词DDD eXchange）的一些网络广播，以便对DDD所包含的内容，有限的上下文和聚合根源有正确的看法。 之后你也应该读他的书，这是一本很棒的读物。 但是你需要他最近的观点（如在这些网络广播中所表达的那样），而不是陷入专注于技术构建模块的陷阱。