域模型和 EF Core 模型答案

【问题标题】：Domain model and EF Core model域模型和 EF Core 模型
【发布时间】：2018-03-15 12:58:57
【问题描述】：

在查看"Should Entities in Domain Driven Design and Entity Framework be the same?" 帖子时，接受的答案指出域实体和 EF 实体只能在首先使用代码时相同。这样实体可以保持“纯净”。

但是，由于这个障碍："Discussion on many-to-Many relationships (without CLR class for join table)"，如果不为关联表（订单实体）指定特殊实体，就无法创建具有产品实体集合的订单实体。

我现在看到同事将这些关联表放入他们的域实体中，我觉得这是错误的，因为它暗示着要应对持久性而不是忠实于域。在我看来，它们不再“纯粹”了。

您是否会说，由于关联表实体，EF Core 中不可能有相同的域实体？我如何在 EF Core 中解决这个问题？

【问题讨论】：

标签： domain-driven-design entity-framework-core

【解决方案1】：

但是在常规/经典 Ordering 域中，需要 orderline（或 order-line-item 或任何您想调用的名称），因为您需要将数量和商品价格存储在产品编号。

在大多数 DDD 示例中，从 DDD 的角度来看，该项目是 Value object，从持久性的角度来看是 Entity。如果您想知道 Value 对象如何成为 ORM 实体，您应该阅读 Vaughn Vernon 的书 Implementing Domain Driven Design 中的 Persisting Value Objects。

但是，在某些情况下，域模型不能 100% 适合持久性模型。在这种情况下，需要将一些元信息附加到域模型以匹配持久性模型。一般来说，您有两种选择：

您可以将元数据添加到一些外部文件中，例如 XML 文件；
- 它的优点是它使域模型在持久性方面不可知，但
- 它的缺点是当域模型发生变化时必须记住要更改外部文件
您可以注释域模型
- 它的优点是通过将信息放在同一个文件中，可以很容易地同时更改Domain模型和Persistence模型；它遵循原则：“一起改变的事物会保持在一起”（Common Closure Principle）
- 它的缺点是会因基础架构问题而污染域模型

如果必须选择，我倾向于选择对域模型进行注释，但您应该自己做出决定。

【讨论】：

感谢您的回答。我猜 orderline 确实是一个不好的例子。我指的是没有额外属性的关联表，除了链接 2 个外键之外没有其他作用。我的感觉是它们不应该成为领域模型的一部分。
@Constantin Galbenu，我赞成这个问题，因为我发现它很有用。您能否解释一下如何使用元数据来允许将 OrderItems 添加到 Order（在域模型中）而不是 OrderOrderItems（OrderOrderItems 是 Order 和 Order Items 之间的连接表）？然后，我将投票赞成答案。谢谢。