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

Question

我正在尝试按照here概述实现多个DDD有界上下文。这是一个示例上下文：

我为每个实体提供了一个实体类型配置文件，其中包含适当的FluentAPI映射（使用EF工具进行反向工程）。这些配置文件还包括关系配置。

例如：UserMap.cs

// Relationships
this.HasOptional(t => t.SecurityProfile)
    .WithMany(t => t.Users)
    .HasForeignKey(t => t.SecurityProfileCode);

上下文中

SecurityProfile和DomainPermission不是DbSets。由于User和Module上的导航属性，它们会自动进入模型。

这导致了我的第一个问题。将User（或任何其他实体）添加到任何其他上下文时，我必须记住做以下两件事之一：

1. 同时将配置添加到SecurityProfile的模型构建器（以及实体上的所有其他关系）

2. 以某种方式明确地从模型中排除SecurityProfile。

这开始成为一种维护噩梦。

我很满意明确“修剪”实体图，如上面第2点所述。

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

针对上述情况modelBuilder.Ignore<SecurityProfile>();尝试OnModelCreating会在ConfigureAssociations()中出现以下错误：

System.InvalidOperationException：导航属性“SecurityProfile”不是“User”类型的声明属性。验证它是否未从模型中明确排除，并且它是有效的导航属性。

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

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

如何在实施有界上下文时最好地管理和维护实体及其实体配置？

Answer 1

由于评论时间过长，此处添加：

非常（非？）有趣的是，您所指的文章显然是试图通过提及一个新的流行语DDD并随后仅显示如何保持DTO / POCO对象来加入潮流在一个背景下。这与DDD无关。

领域驱动设计主要是关于行为和封装（基础设施隔离/无知）模型，这些模型经过迭代探索和改进，以解决特定参与者的特定问题，并在问题域的ubiquitous language中表达。

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

我建议你观看Eric Evan关于技能人员（关键字DDD eXchange）的一些网络广播，以便对DDD所需的内容，有限的上下文和聚合根源有正确的认识。之后你也应该读他的书，这是一本很棒的读物。但是你需要他最近的观点（如在这些网络广播中所表达的那样），而不是陷入专注于技术构建模块的陷阱。