値オブジェクトにIDを置くのは悪いIDですか？
シリアルアドレスを持つことができる顧客がいます。 Serevalのお客様は、同じ住所に住んでいる可能性があります。したがって、私のリレーショナルデータベースでは、古典的な多対多の関係です。
なので ：
- 住所は変更できません（お客様は住所を変更できます）。
- 副作用のあるロジックは含まれません。
- そして、2つのアドレス間の公平性は、その値によってのみ決定されます。
私は、アドレスは価値のあるオブジェクトの良い候補だと主張します。
ただし、顧客の住所を永続化する必要がある（またはそうでない場合もある）ため、IDを追加する必要があります。
私は少し混乱しており、苦労しています。純粋なドメインロジックと一般的な感覚からすると、値のオブジェクトであることがわかりますが、テクノロジーの制約により、アドレスにIDがあることがわかります。
値オブジェクトを保存しても問題ありませんか？
住所オブジェクト（番地を参照）は、値オブジェクトまたはエンティティのいずれかとしてモデル化できます。トレードオフは主にデータベース/ストレージ層にあります。
アドレスオブジェクトにIDを割り当てるようにストレージを設計する場合、アドレスオブジェクトをエンティティとして扱うことを効果的に選択しています。
アドレスを値オブジェクトとして扱いたい場合は、それらをCustomerテーブル（顧客ごとのアドレスの固定数に制限する）内、または主キーを持たないが外部キーを使用してテーブルに保存することができます。顧客テーブル。これは、複数の顧客がアドレスを共有する状況を表すことができないことを意味します。各顧客はストレージに独自のアドレスレコードを取得するためです。
同じタイプの複数の値オブジェクトをエンティティに関連付けることは、一般的なユースケースです。
私が通常行うことは、値オブジェクトを別の方法でモデル化し、値オブジェクトのコレクションをエンティティに関連付ける方がよいかどうかを理解することです。
したがって、あなたの場合、値オブジェクトは実際にはAddressCollection値オブジェクト（コード内）であり、DB（エンティティの同じテーブル）または別のテーブルにシリアル化されたデータとして格納することを選択できます。ここで、各行のIDは、行の値の構成にすることができます（そうする必要があります）。