DDD值对象

时间:2016-06-30 08:49:36

标签: domain-driven-design

引用埃文斯蓝皮书

  

您可能会惊讶地发现我们应该努力使用模型   尽可能使用值对象而不是实体。即使是一个   域概念必须建模为实体,即实体的设计   应该偏向于作为一个价值容器而不是一个   子实体容器。这个建议不是基于任意的   偏爱。衡量,量化或描述事物的价值类型   更容易创建,测试,使用,优化和维护。

把它放在我的上下文中,我有

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

每张发票都有发行人。我应该通过ID将其视为Invoice-> Issuer关系,或者更好的做法是将其视为一个引用Issuer的值对象,或者将此发行者简单地视为从Issuer AR创建的值对象

所以在这种情况下它将是

1

  Invoice
    -InvoiceId
    -IssuerId

VS

Invoice
-InvoiceId
-InvoiceIssuer
  -IssuerId
  -FullName

VS

Invoice
 -InvoiceId
  -InvoiceIssuer
   - Fullname

我倾向于向第2号解决方案倾斜,因为如果发行人的名字由于某种原因而发生变化,我在发票创建时仍会有发行人的名称,并且提及改变其名字的发行人。

这背后的逻辑是,如果我尝试打印一张旧发票,在发行人更改其名称之后,我仍然会在其旧状态下开具发票,因为它首先打印出来,但如果我仍然是能够找到该发行人的所有发票,即使他改名了。

创建值对象是否通过ID有效方法引用另一个实体,或者我在这种情况下做错了什么?

1 个答案:

答案 0 :(得分:3)

  

“我倾向于向第2号解决方案,因为如果发行人的名字   由于某种原因不断变化,我仍然会有发行人的名字   在发票创建时,以及对更改的发行人的引用   他的名字。“

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

肯定有一些你可以努力遵循的建模最佳实践(赞成价值对象,设计小聚合等),但最后DDD是关于制作特定领域的模型,这样的模型只能受到批评而且只能被批评在其问题域的背景下具有价值。

当您寻求验证模型时,请关注商业行为&不变量首先。