使用实体和值对象建模域时,将“基本”值类型定义为定义好的值对象是否有意义?
例如,我可以拥有一个值对象EmailAddress或ProductName。但是String只是一个价值对象呢?是否有任何正当理由反对任何已知原则?我真正想知道的是,我是否应该/可以将所有可能的属性值定义为值对象,包括字符串,bool,int等。这是错误的还是只是做到了远?不知何故,我觉得我更愿意明确表达任何某种价值的“事物”而不是任何可以解释的东西。你怎么看?大师们对此有何看法?
A reference我偶然发现:
替换常见基元(例如字符串)通常是个好主意 使用适当的值对象。虽然我可以代表一个电话 数字作为字符串,变成电话号码对象使 变量和参数更明确(当类型检查时 语言支持它,是验证和避免的自然焦点 不适用的行为(例如对整数id进行算术运算 号码)。
答案 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
,真是巧合......