领域模型和EF Core模型

Question

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

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

我现在看到同事们将这些关联表加入他们的领域实体，我认为这是错误的，因为它暗示着应对持久性，而不是真正符合领域。在我看来，它们不再“纯洁”。

您会说由于关联表实体而在EF Core中无法拥有相同的领域实体吗？我该如何在EF Core中处理这个问题？

- XWIKO

Answer 1

但是在一个常规/经典的Ordering领域中，需要一个orderline（或订单行项目，或您想称之为什么）因为您需要存储数量和商品ID以及商品价格。在大多数DDD示例中，从DDD角度来看，该项是一个值对象，而从持久性角度来看，则是一个实体。如果您想知道值对象如何成为ORM实体，则应阅读Vaughn Vernon的书《实现领域驱动设计》中的“持久化值对象”一章。

然而，在某些情况下，领域模型与持久性模型并不完全匹配。在这种情况下，需要为领域模型添加一些元信息，以匹配持久性模型。通常有两个选择:

- 您可以将元数据添加到一些外部文件中，例如XML文件; - 它的优点是保持领域模型对持久性的不可知性， - 缺点是当领域模型更改时必须记得更改外部文件。 - 您可以注释领域模型 - 它的优点是通过将信息保存在同一个文件中，很容易同时更改领域模型和持久性模型；它遵循“一起变化的东西呆在一起”原则。 - 缺点是它会污染领域模型与基础设施相关的问题。

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

- Constantin Galbenu

---

感谢您的回答。我想orderline确实是一个不好的例子。我指的是没有额外属性的关联表，其唯一作用是链接2个外键。我的感觉是它们不应该成为领域模型的一部分。 - XWIKO

@Constantin Galbenu，我已经点赞了这个问题，因为我觉得它很有用。您能解释一下如何使用元数据来允许将OrderItems添加到订单（在领域模型中），而不是OrderOrderItems（OrderOrderItems是订单和订单项之间的连接表）吗？然后我会点赞答案。谢谢。 - w0051977