エンティティの既知のビジネスIDは、DDD / OOPの専用タイプで表す必要がありますか？

実際には、カスタムタイプ（不変）classをstring他のプリミティブ型の上で使用することを意味します。

例：

1. 出版：国際標準図書番号。
2. 金融：国際証券識別番号。

利点：

1. 識別子の形式を確認できます。
2. モデルのファーストクラスのメンバーになります。

短所：

1. 永続化の摩擦を追加します（例：Entity Framework）。
2. より多くのコード。

文字列ではないという複雑さを正当化するのに十分な便利な機能をクラスに与えることができる場合は、それを実行してください。ISBNやISINのような識別子については、そうではないと思います。

識別子クラスが役立つためには、次のようになると思います。

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

代わりに、次のようになります。

class ISIN {
    getString()
    setString()
}

次に、クラス全体を破棄し、すべての場所で通常の文字列を使用し、関連するすべての変数名で一貫して「isin」を使用していることを確認します。

一部の言語では、新しい型を追加しても、通常のプログラムではほとんど「複雑さが追加」されないことに注意してください。その場合、機能がまったくない場合でも、新しい型を作成することをお勧めします。しかし、これはC ++のようなほとんどの従来のOOP言語には当てはまりません。

私はそれのために行くと言うでしょう。この場合、利点が欠点を上回ると主張します。追加のコードはかなり少なくなる可能性が高く、永続性の問題は、新しいクラスとデータベースが期待するタイプの間で何らかのコンバーターを提供することでかなり簡単に解決できます（私はEntity Frameworkを使用したことがありませんが、これは比較的簡単です。ハイバネート）。

独自のクラスを定義することで得られる利点の1つは、ISBNまたはISINを必要とするメソッドが、間違った値を渡して渡した場合に、コンパイル時にコンパイラが確実に認識できることです。また、エンティティのそのフィールドを誤って上書きすることもはるかに困難になります。このような一般的なエラーは完全に回避できます。

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

ISBNがプリミティブ型ではなくクラスの場合、上記のコードはコンパイルすらできず、後でデバッグ時間を大幅に節約できます。