具有 DDD 有界上下文的实体配置管理答案

【问题标题】：Entity configuration management with DDD bounded contexts具有 DDD 有界上下文的实体配置管理
【发布时间】：2013-09-02 10:25:10
【问题描述】：

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

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

例如：UserMap.cs

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

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

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

还将SecurityProfile（以及实体上的所有其他关系）的配置添加到模型构建器中
以某种方式从模型中明确排除SecurityProfile。

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

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

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

尝试modelBuilder.Ignore<SecurityProfile>(); 用于上述上下文OnModelCreating 在ConfigureAssociations() 中会出现以下错误：

System.InvalidOperationException：导航属性“SecurityProfile”不是“用户”类型的声明属性。验证它没有被明确地从模型中排除，并且它是一个有效的导航属性。

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

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

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

【问题讨论】：

考虑到EF Project Site 声明“关于在您的应用程序中使用实体框架的问题，请使用实体框架标签在 Stack Overflow 上发布问题。”
如果您查看近距离投票，您会发现它“太宽泛”。我同意这一点。你有三个问题，一个都没有。附注：DDD 说您的实体应该是持久性无知的，而您的实体则不是，因为您显然必须更改它们以使其符合 EF 的要求。
@jgauffin 我很乐意将 3 个问题浓缩为第 3 个问题。然而，这不是一个简单的“我该怎么做”问题，背景信息对所有 3 个问题都有帮助。因此，考虑到 SO 是提出此类问题的推荐途径，因此它“太宽泛”的原因是无效的。也许这是开源项目劫持 SO 作为其社区渠道的问题。但似乎没有任何其他选择，这是我希望得到回应的唯一途径。
@HonorableChow 我同意并且我得出了同样的结论。这个article 和这个thread 很有帮助。我认为最好的解决方案是将所有内容都保留在特定于该上下文的上下文中。我开始接受这样一个事实，即定制类爆炸是这种架构不可避免的结果。
@BrettPostin 我不认为这是 EF 特有的问题。您的有界上下文不应泄漏到其他有界上下文中，否则它不再是有界的。真正的聚合设计只存储聚合之外元素的键。对于有界上下文也是如此。我不知道你是否已经读过 Vaughn Vernons 的书 (amazon.com/Implementing-Domain-Driven-Design-Vaughn-Vernon/dp/…)，但它对我理解有界上下文有很大帮助

标签： c# entity-framework domain-driven-design

【解决方案1】：

由于 cmets 有点太长了，所以在这里添加：

非常（不）有趣的是，您所指的文章显然是试图通过提及一个新的流行词DDD 来赶上潮流，随后只展示了如何将 DTO/POCO 对象保存在一个语境。这与 DDD 完全无关。

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

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

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

【讨论】：

我已经阅读了this Evans 支持他的 DDD 书的摘要，并且完全理解您的观点。然而考虑到所有这些，我的模型实际上是独立于技术的，在某些时候它需要持久化到数据库中。这是对持久性策略的管理，同时保持我正在寻找答案的 DRY 原则。在不同的模型中拥有“相同”的实体但具有不同的关系会导致映射重复问题和潜在的未来维护问题。
@BrettPostin 你可能还想看看我提到的网络广播，我相信它们可能会让人大开眼界（我刚刚检查过，不幸的是他在 2008 年的精彩介绍视频和他的其他谷歌文档托管的演员表没了，但至少看这个，只有15分钟，表达了Eric最近的一些经历和观点：skillsmatter.com/podcast/design-architecture/welcome-eric-evans)。