查看帖子"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中无法拥有相同的Domain实体？我该如何在EF Core中应对呢？
最佳答案
但是在常规/经典Ordering域中，需要一个orderline（或订单行项目或任何您想称呼的项目），因为您需要沿着产品ID存储数量和商品价格。
在大多数DDD示例中，从DDD的角度来看，此项目是Value object，从持久性的角度来看，则是Entity。如果您想知道Value对象如何成为ORM实体，应该阅读沃恩·弗农（Vaughn Vernon）的《 Persisting Value Objects》一书中的Implementing Domain Driven Design。
但是，在某些情况下，域模型不能与持久性模型完全匹配100％。在这种情况下，需要将一些元信息附加到域模型上，以匹配持久性模型。通常，您有两种选择：
您可以将元数据添加到某些外部文件，例如XML文件；
它的优势在于，它使Domain模型在持久性方面不可知，但是
它的缺点是，当域模型更改时，必须记住要更改外部文件
您可以注释域模型
其优点在于，通过将信息存储在同一文件中，可以轻松地同时更改域模型和持久性模型；它遵循的原则是：“改变在一起的事物保持在一起”（共同封闭原则）
它的缺点是会污染基础结构方面的领域模型
如果必须选择，我倾向于选择对域模型进行注释，但是您应该自己做出决定。
关于domain-driven-design - 域模型和EF Core模型，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/49300110/