DDD值对象

Question

引用埃文斯蓝皮书

我们应该努力使用值对象来建模，而不是在可能的情况下使用实体，这可能会让您惊讶。即使必须将域概念建模为实体，实体的设计也应该偏向于充当值容器而不是子实体容器。这一建议并不是基于任意的偏好。测量、量化或描述事物的值类型更容易创建、测试、使用、优化和维护。

把它放在我的上下文里，我

• 以发票实体为AR的发票汇总
• 以发行人实体为AR的发行人集合

每张发票都有发票。我应该通过ID将其视为一个发票-> Issuer关系，还是将其视为引用issuer的值对象，还是将其简单地视为从Issuer AR创建的值对象是一种更好的做法

所以在这种情况下

1.

  Invoice
    -InvoiceId
    -IssuerId

VS

Invoice
-InvoiceId
-InvoiceIssuer
  -IssuerId
  -FullName

VS

Invoice
 -InvoiceId
  -InvoiceIssuer
   - Fullname

我倾向于扭转解决方案2，因为如果签发人的名字因某种原因而发生变化，在发票创建时，我仍然会有发行人的名字，并提及更改其名称的签发人。

这背后的逻辑是，如果我试着打印一张旧的发票，在签发人改名后，我仍然会有发票处于旧的状态，因为它最初是这样打印的，但是如果我仍然能够找到那张发票的所有发票，甚至他也会改名。

通过ID创建具有引用另一个实体的值对象是有效的，还是在这种情况下我做错了什么？

Answer 1

“我倾向于第2号解决方案，因为如果签发人的名字因某种原因而发生变化，在发票创建时，我仍然会有签发人的名字，并提及更改其名称的签发人。”

你已经自己回答了这个问题。唯一符合上述要求的模型是#2。

确实有您可以努力遵循的建模最佳实践(偏爱值对象、设计小聚合等等)，但最终DDD是关于构建特定于领域的模型的，这样的模型只能受到批评，并且只有在它的问题域的上下文中才有价值。

当您试图验证您的模型时，首先要关注业务行为&不变量。