DDD,不同领域模型是否可以依赖同一套表

DDD, can different domain models rely on the same set of tables

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

谢谢,

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

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

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

DDD 中的一个关键思想是限界上下文,它包含以下几项内容:

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

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

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

Vaughn Vernon 的书 "Implementing Domain Driven Design" 第 66 至 68 页对这个问题进行了很好的讨论。

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

实体和 table 之间的 "disappointing [1:1] mapping" 可能会在两个方面让您失望——无法从多个 table 填充一个实体,以及无法填充来自同一 table.

的多个实体

您似乎对后者更感兴趣,这对于大多数 ORM 都是可能的,即使仅通过在 ORM 的单独映射 "instances" 中为一个 table 定义不同的映射。 Entity Framework 的解决方案描述为 here and here