web-dev-qa-db-ja.com

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

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

例：

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

利点：

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

短所：

  1. 永続化の摩擦を追加します（Entity Frameworkなど）。
  2. より多くのコード。
object-orienteddomain-driven-designdomain-modelentityvalue-object
9
Den

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

識別子クラスが役立つためには、次のようになるはずです。

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

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

class ISIN {
    getString()
    setString()
}

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

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

6
Ixrec

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

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

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

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

6
Matt Watson