【问题标题】:Domain Driven Design - Value Object or Entity领域驱动设计 - 值对象或实体
【发布时间】:2013-12-07 07:59:03
【问题描述】:

我有一个关于在下面的案例中识别值对象以及我必须如何实现它的问题。

案例:

在在线社区中,用户可以创建自己的私人/公共页面(例如 Facebook)。在此页面中,他们可以发布帖子等。这些帖子可以由其他用户评分。不仅帖子可以评分,而且整个页面都可以被其他用户评分。

因此,如果我尝试对此进行建模,我最终会得到 3 个实体(页面、用户、帖子),它们在此内容中都有唯一的身份。 但是收视率呢?我倾向于使用价值对象,因为评级在此内容中没有足够的身份(没有它可以存在帖子或页面)并且没有用户就无法存在。

问题:它是一个值对象还是一个实体:)

谢谢!

【问题讨论】:

    标签: entity domain-driven-design value-objects domain-object


    【解决方案1】:

    在我看来,您的评分系统是高度并发的,因为您期望多个并发用户对单个 AR 进行评分。如果有两个并发评级,这肯定会导致陈旧的 AR 出现大问题。你最好让你的评级成为他们自己的 AR,以允许同时创建单个帖子/页面的评级,例如,参见 Vaughn Vernon 的 IDDD 书中他谈论并发用户。

    【讨论】:

    • 嗯好的洞察力,但你是说评级是一个实体?对于 AR,您的意思是聚合根对吗?
    • 是的,我建议将其建模为一个实体(AR=Aggregate Root)。其他聚合根(页面、帖子)可以异步更新,例如,全部 5 分钟(最终一致性)。
    【解决方案2】:

    根据您对问题的描述,Rating 是一个值对象。

    值对象确实是领域专家和用户可以用来描述实体质量但未被识别的东西。

    Rating 类可以通过shared identifiers 持有对用户实体的引用,而 Post 类可以有一个类似void Register(Rating rating) 的命令。

    【讨论】:

    • 感谢您的快速回复!但是在值对象中声明引用不是一个坏习惯吗?当然是它的主人?这就是我困扰的问题;)
    【解决方案3】:

    当你试图将一个对象作为值对象时,不要只考虑它的身份。值对象应该是不可变的,并且在应用程序中不要太多,例如品牌。世界上所有的品牌都不过是一个系统的用户或页面。或金钱和地址在某些情况下 由于并非每个对象都有标识,因此值对象是为了降低复杂性,而不是通过两种方式选择一个对象作为实体或值对象来使现有问题变得更复杂! 在您的情况下: page 、 user 和 post 可以是聚合的实体,也可以是聚合根(基于您的应用程序),但系统的费率可以是实体或值对象。如果它没有身份让您通过聚合根检索它,则将其分配为值对象,但在其他情况下,它可能是聚合的实体。 看看这篇关于 DDD 的简短博客文章: http://www.ehsanghanbari.com/Post/15/domain-driven-design-alphabet

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2020-10-26
      • 1970-01-01
      • 2015-02-27
      • 2011-08-01
      • 1970-01-01
      • 2011-05-26
      • 2016-01-25
      • 2011-01-30
      相关资源
      最近更新 更多