6

我正在尝试实现此处概述的多个 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”不是“用户”类型的声明属性。验证它没有被明确地从模型中排除，并且它是一个有效的导航属性。

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

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

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

4

1 回答 1

1

由于评论太长，在此处添加：

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

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

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

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

于 2013-09-02T02:25:10.867 回答