DDD，不同领域模型能否依赖同一套表答案

【问题标题】：DDD, can different domain models rely on the same set of tablesDDD，不同领域模型能否依赖同一套表
【发布时间】：2015-06-21 16:07:33
【问题描述】：

在 DDD 中，一条准则指出域模型不应该与持久性有关。这意味着不同的域模型可能依赖于相同的表。同时，这个目标似乎很难实现，因为 ORM 在转换模型方面存在技术限制（我想？）。有没有办法使用实际的 ORM 来创建依赖于数据库中相同表的非常具体的域模型，并防止我们在 99.99% 的 DDD 实现中出现的实体和表之间令人失望的 [1:1] 映射？这些技术限制 (?) 是否会使指南过时？

谢谢，

【问题讨论】：

“这意味着不同的域模型可能依赖于同一个表”……这个说法不清楚？什么意思？
你需要将一个实体映射到多个表还是将多个实体映射到一个表？
我需要将多个实体映射到同一个表，但方式不同。在一些表中提取一些数据并将其映射到不同的实体，以创建域（例如：一个用于欺诈检测，一个用于管理功能等......）。如果我不能做到这一点，它就会带来重复数据的问题。我在复制数据方面遇到了真正的问题。我知道它有时是有道理的，也许我会发布一个关于那个的问题......
嗯，有时您甚至必须将一个实体映射到两个不同的数据库，例如 redis 和 mysql。不幸的是，实体框架大多数时候不允许我们这样做，所以你不能基于它们。
@Rénald 这种方式实际上对于大多数 ORM 都是可行的。是什么让你认为不是？你试过了吗？

标签： domain-driven-design persistence

【解决方案1】：

实体和表之间的“令人失望的 [1:1] 映射”可能会在两个方面让您失望 - 无法从多个表中填充实体，以及无法从同一个表中填充多个实体。

您似乎对后者更感兴趣，即使仅通过在 ORM 的单独映射“实例”中为一个表定义不同的映射，大多数 ORM 也是可能的。描述了实体框架的解决方案here 和here。

【讨论】：

【解决方案2】：

我想答案取决于您的域模型与您的数据库表的不同之处。有时您可能无法单独使用 ORM 实现 DDD 持久性。这不应阻止您或导致您围绕数据库设计域模型。这也是 DDD 有存储库接口概念的原因，因为持久化模型的任务可能非常复杂。

该指南现在并不比最初编写时更过时。 ORM 可能与本指南兼容，也可能不兼容，但这并不意味着使用其他方法无法实现。

我同意您的评估，即大多数 DDD 模型是数据库的 1:1 镜像。简短的回答是，坚持并不总是那么容易，但绝不是不可能的。

【讨论】：

谢谢，我会检查一下 .NET 的数据映射器模式实现。

【解决方案3】：

如果你使用 Java，你可以使用遵循 Data Mapper 模式的 MyBatis 来实现。

【讨论】：

非常有趣。似乎有一个用于 .NET 的 MyBatis 端口。我会尽快检查。感谢您的贡献。

【解决方案4】：

DDD 中的一个关键思想是有界上下文，其中包含以下内容：

无处不在的语言
聚合根
实体
域服务
领域事件
数据库表

DDD 可能会出现两种情况，具体取决于项目是绿地还是棕地的天气。

在一个使用 DDD 完成一切的绿地项目中，将有清晰的子域、清晰的限界上下文，您将拥有被视为在限界上下文中的数据库表，并且您将获得表之间的 1 : 1 映射JPA / Hibernate ...等的实体。
在具有无法更改的现有数据库的棕色字段项目中，一个数据库可以支持多个有界上下文，并且某些表可能会将其列的不同部分映射到不同有界上下文中的不同域实体。

Vaughn Vernon 所著的“实施领域驱动设计”一书的第 66 至 68 页对这个问题进行了很好的讨论。

【讨论】：