我一直在努力思考 DDD 以及它与 MVC 的关系，但我在实体识别方面遇到了麻烦。
特别是，我试图在我的演示文稿、域和数据模型之间保持严格的分离。我的问题在于我如何跨这些边界保存实体标识。澄清一下，我使用不同的类来表示不同上下文中的同一实体 - 例如，我有一个“ShipmentRequest”域类、几个“ShipmentRequestView”表示类（取决于特定视图所需的属性）和一个'shipment_request' 数据库表（我的数据模型）。
我觉得使用“ID”属性（如 ShipmentRequestId）会违反我试图实现的分离，因为此 ID 属性是数据库问题，而不是域问题；而且我不想在层之间传递相同的对象，因为这意味着将不需要的数据传递到我的表示层。
如何保持这种分离，同时跟踪这些层之间的身份？
【问题讨论】：
标签： mapping domain-driven-design separation-of-concerns
如果您的实体中没有 Id 字段，您将无法将其映射到数据库行。因此，即使这个 id 字段与您的实体无关，它也必须泄漏到您的域模型中。
我觉得使用表示模型通常是矫枉过正的，特别是如果您想要实现的是隐藏某些属性。
我认为关注点分离主要是由有界上下文驱动的。例如，您的 Person、PersonView 和 Person 表似乎都与事务处理上下文有关。在这种情况下，我什至没有 PersonView 并且 person 表将被抽象掉。
另一方面，如果您在报告上下文中，PersonView 会更有用。
我认为上下文比任何分层方案都重要。
至于您的 person 实体中缺少自然键，这可能意味着 Person 不是真正的实体。例如，在任何现实生活中的应用程序中，总是有一个与人相关联的号码：员工有员工号码，客户作为帐号等。这个企业 id 肯定是域的一部分。
【讨论】：
我认为在实体上设置“ID”字段是很多（大多数？）人们最终做出的让步，我不会为此感到内疚。
正如您所说，即使您不处理数据库，您仍然需要一些身份概念。您可以尝试为每个实体（名称等字段或多个字段的组合）提出某种“自然”身份，但这并不总是可行的。即使是这样，拥有一个 ID 字段通常也可以作为一种方便的简写形式来表示“名称为 X、出生日期为 Y、SSN 为 Z 的实体”。
最后，虽然可以说不那么“纯粹”，但拥有一个 ID 字段可能会大大简化事情。
【讨论】：
Shipment Request 绝对是一个更好的例子！
用户如何找到发货请求？ 根据答案，您可能需要用户可能记得的 id，例如 20091012-A。
装运请求 ID 可以更改吗？ 如果否，请使用 db 密钥作为标识。
您是否需要将装运请求从一个系统转移到另一个系统？ 如果是，请不要使用 db 密钥作为标识。
无论您使用什么键，您都需要使其在演示模型中可用，以便您可以建立指向特定装运请求操作的链接。
【讨论】：