Javaのドメイン駆動設計 - すべてのプリミティブをバリューオブジェクトに変換する

Question

JavaのDDDは、通常、ドメインの一部であるすべてのプリミティブを値オブジェクトに変換することを意味しますか？私は今日、同僚とのStringly（厳密には強力な）型付きコードに関する同僚との議論を行ってきました。私は、物事を分離するバリューオブジェクト（まあ、エンティティではないもの）にすべてを変えるというのが大好きですが、構造体（住所、通り、家の番号など）の場合には、 、など）、または組み込み検証が関連する場合（電話番号のような場合）。たとえば、ペットの名前を別のラッパークラスに入れるなど、残念ながら（ロンボクのようなフレームワークであっても）、それとも一見すると簡単に見つけられない大きな利点がありますか？

Answer 1

これはルールではありませんが、コードにはビジネス言語ができるだけ反映されている必要があります。理解できるビジネス名詞にプリミティブ値を変更することをお勧めします。値オブジェクトが非常に単純な場合でも（単一のvalueプロパティを持つ）、明示的に名前を付けると、それらのオブジェクトを推論するのがはるかに簡単です。それに加えて、あなたのオブジェクトは、あなたのモデル/ドメインのナレッジ・クランチングの間に変わる可能性があります。ある日、あなたの単一価値オブジェクトは複雑な検証を伴うより複雑な構造に変わることは非常に可能です。値オブジェクトを意味のあるクラスとして最初から設計すると、リファクタリングがはるかに簡単になります。静的型検証の利点も得られます。ストリートアドレスとしてペットの名前を設定することはできません（単純な文字列としてモデル化した場合のみ可能です）。

Answer 2

これは、一目で発見するのは容易ではない大きな利点をもたらしますか？

大きな利点の1つは、ビジネスロジックをメモリ内のデータの表現から切り離すことです。たとえば、お金を整数、ロング、固定小数点、または浮動小数点として表現しているかどうかは、請求処理ロジックではまったく気になりません。購入価格に税率を適用するようなことが気になります。

したがって、値の種類は単なる「タグ」以上のものであり、ユニットや丸めルールなどを入れたり、税金や税金などの重要な区別を追跡するのに便利です。

また、さまざまな概念を明らかにして明確にすることもできます。Addressは出荷ラベルに記載されていますか？地図上の場所？不動産のタイトル？税管轄の一部ですか？法的管轄の一部ですか？

強力な型の安全性を組み合わせると、コーディングエラーによってビジネスエラーが発生していないことを確認できます（前と後の税額を合計するなど）。