标准值类型为DDD中的ValueObjects?

时间:2018-03-27 10:06:38

标签: domain-driven-design value-objects

使用实体和值对象建模域时,将“基本”值类型定义为定义好的值对象是否有意义?

例如,我可以拥有一个值对象EmailAddress或ProductName。但是String只是一个价值对象呢?是否有任何正当理由反对任何已知原则?我真正想知道的是,我是否应该/可以将所有可能的属性值定义为值对象,包括字符串,bool,int等。这是错误的还是只是做到了远?不知何故,我觉得我更愿意明确表达任何某种价值的“事物”而不是任何可以解释的东西。你怎么看?大师们对此有何看法?

A reference我偶然发现:

  

替换常见基元(例如字符串)通常是个好主意   使用适当的值对象。虽然我可以代表一个电话   数字作为字符串,变成电话号码对象使   变量和参数更明确(当类型检查时   语言支持它,是验证和避免的自然焦点   不适用的行为(例如对整数id进行算术运算   号码)。

2 个答案:

答案 0 :(得分:2)

DDD中的值对象是一件好事,它们是不可变的,因此它们可以安全地传递,它们以一种漂亮的OOP模式包含数据及其行为(如果使用OOP)。它们也使隐式显式并提供强类型。

如果您需要上述任何功能,那么您应该为任何需要它的属性创建一个Value对象(类,组件......以您的语言存在的任何内容)。

但是,如果您不需要上述任何一项,那么您就不应该这样做。您不会仅因为某些“大师”这样说而创建新类,例如every property of an Aggregate should be a Value object

最重要的方面是,如果你有一些具有数据和行为的属性,并且你需要为它创建一个Class,那么该类应该是一个Value对象,特别是它应该是不可变的(不包括实体)

答案 1 :(得分:0)

您可能需要阅读" Out of the tar pit"白皮书或观看DDD挪威聚会的talk by Romeu Moura

原始类型有助于隐式显式。默认情况下,它们是隐式。这使得系统无限复杂,因为这种系统的状态数是不确定的。

我同意课程可能会成为负担。您可能确实避免使用值对象,但是您需要接受您的无所不在的语言不再普遍存在。无处不在意味着语言在任何地方都被使用,包括代码。你不能说"产品名称"到域期望,然后回到你的代码,看到"字符串"。这也不会将您的域语言传达给其他开发人员。

Yves Reinhout在去年的KanDDDinsly会议上发表了关于这些事情的great talk,建议观看。

我个人真的希望新的OO语言功能,比如提议的C#记录类型,使事情变得像函数式语言一样简单。顺便说一下,在功能语言中阅读类型系统也为OO程序员提供了许多很好的见解。例如,F#for Fun和Profit具有此great article about types and DDD。顺便说一句,它首先看string,真是巧合......