Mapping 领域驱动设计、SOC和实体识别

我一直在试图将我的想法围绕DDD以及它与MVC的关系，但我在实体识别方面遇到了问题

特别是，我试图在表示、域和数据模型之间保持严格的分离。我的问题在于如何跨越这些边界保存实体标识。为了澄清这一点，我使用不同的类在不同的上下文中表示同一实体——例如，我有一个“ShipmentRequest”域类、几个“ShipmentRequestView”表示类（取决于特定视图所需的属性）和一个“ShipmentRequest”数据库表（我的数据模型）

我觉得使用“ID”属性（如ShipmentRequestId）违反了我试图实现的分离，因为这个ID属性是数据库问题，而不是域问题；我不想在层之间传递相同的对象，因为这意味着将不需要的数据传递到表示层

如何保持这种分离，同时跟踪这些层之间的身份？

我认为在实体上有一个“ID”字段是很多人（大多数？）最终做出的让步，我不会为此感到内疚

正如您所说，即使您不处理数据库，您仍然需要一些身份的概念。您可以尝试为每个实体提供某种“自然”标识（类似于字段的名称，或几个字段的组合），但这并不总是可能的。即使是这样，拥有一个ID字段也常常充当一个方便的缩写，表示“名称为X、出生日期为Y、SSN为Z的实体”

---

最后，虽然可以说没有那么“纯粹”，但拥有一个ID字段可能会大大简化事情。

如果实体中没有ID字段，则无法将其映射到数据库行。因此，此id字段即使与实体无关，也必须泄漏到域模型中

我觉得使用一个表示模型通常是过分的，尤其是当您试图实现的是隐藏一些属性时

我认为关注点的分离主要是由有限的上下文驱动的。例如，Person、PersonView和Person表似乎都与事务处理上下文相关。在这样的上下文中，我甚至不会创建PersonView，person表也会被抽象掉

另一方面，如果您处于报告上下文中，PersonView会更有用

我认为上下文比任何分层方案都重要得多

---

至于在你的个人实体中缺少一个自然键，这可能意味着这个人不是一个真正的实体。例如，在任何实际应用程序中，总是有一个与此人相关联的号码：员工有一个员工号码，客户作为账号，等等。此业务id肯定是域的一部分。

发货请求肯定是一个更好的例子

用户将如何找到装运请求？ 根据答案，您可能需要用户可能记得的id，例如20091012-A

装运请求id是否可以更改？ 如果否，请使用db密钥作为标识

您是否需要将装运请求从一个系统转移到另一个系统？ 如果是，请不要将db密钥用于标识

---

无论您使用什么键，都需要在演示模型中提供该键，以便您可以建立指向特定发货请求的操作的链接。

这可能是我最终不得不做的事情。谢谢你的回答。=）如果一个人不是一个实体，那它是什么？它不能是值对象-多个物理人可以具有相同的名称和其他属性。不管怎样，我用Person作为例子，而不是我实际工作的领域的代表。也就是说，你关于上下文的观点很重要。谢谢Person经常被用作人们使用的标准示例，但我认为这是一个不好的示例，因为没有上下文。假设我正在进行人口统计分析，我不关心任何特定个人的id，我只关心其属性。在这种情况下，Person可能是一个值对象吗？我想这取决于所讨论的属性。在这方面，我要这样说。这个例子的优点是——也许我会用一个更好的问题来重构我的问题。用户通过搜索机制或列出属于客户的SRs等来查找SRs。ID可以用来（例如在电子邮件中）指出特定的SRs，但SRs永远不会被其他系统使用。我想DB键是解决这个问题的方法。