实体的知名业务ID是否应在DDD / OOP中用专用类型表示？

9

实际上，这意味着class对一个string或其他一些原始类型使用自定义（不可变）。

例子：

出版：国际标准书号。
财务：国际证券识别码。

优点：

可以确保标识符的格式。
成为模型的一流成员。

缺点：

增加持久性摩擦（例如，实体框架）。
更多代码。

— 登
source

您应该使用自定义类吗？当然。您是否应该将它们用作ID？绝对不是:)具有商业意义的ID会在整个过程中引起麻烦。

— Songo 2015年

2

@Songo对我来说，这是ID应该具有值语义的论点，但是原始类型并不是唯一具有值语义的类型，因此不一定排除imo类。尽管我忘了提出要点了，但还是可以发表一个有竞争性的答案。

— Ixrec 2015年

1

我的一个老问题以不同的观点触及了这个主题：programmers.stackexchange.com/questions/281827/…我继续创建类型并继续这样做。

— 谢夫

6

如果您可以为该类提供足够有用的功能，以证明不是字符串的增加的复杂性，请执行此操作。对于ISBN和ISIN之类的标识符，我怀疑情况并非如此。

为了使标识符类有用，我希望它看起来像这样：

class ISIN {
    fromCUSIP()
    fromRawISINString()
    toString(ISIN::FormatType)
    getExchange()
    getCountryCode()
    getLastFourDigits()
    getWhateverCode()
    ...
}

如果相反，它看起来更像这样：

class ISIN {
    getString()
    setString()
}

然后，我将完全放弃该类，在所有地方使用常规字符串，并确保在所有相关变量名称中始终使用“ isin”。

请注意，在某些语言中，添加新类型在典型程序中几乎没有“增加的复杂性”，在这种情况下，即使根本没有任何功能，也应鼓励您创建新类型。但这对于大多数传统的OOP语言（例如C ++）而言并非如此。

— 伊克斯雷克
source

6

我会说去。在这种情况下，我认为优势大于劣势。额外的代码可能非常少，并且可以在新类和数据库期望的类型之间提供某种转换器来轻松解决持久性问题（我从未使用过Entity Framework，但我知道这在休眠）。

通过定义自己的类可以获得的优点之一是，编译器可以确保如果尝试传递错误的值，则任何需要ISBN或ISIN的方法都将在编译时知道。意外覆盖实体中的该字段也将更加困难。我们可以完全避免这样的常见错误：

book.setAuthor(otherBook.getAuthorName());
book.setIsbn(otherBook.getAuthorName());
book.setPrice(otherBook.getPrice())

如果ISBN是类而不是原始类型，则以上代码甚至都不会编译，从而节省了大量调试时间。

— 马特·沃森
source

1

设置者和获取者？是1992年吗？

— Miles Rout 2015年