アドレスデータがエンティティである理由

Question

私はいつも、アドレスデータは不変であり、その等価性はすべてのフィールドの同じデータによって定義されるため、値オブジェクトであると考えています。たとえば、支払いの一部の請求先住所と配送先住所は、注文または履行の一部です。誰かが住所を変更すると、新しい住所データが必要になります。しかし、私が実行したサンプルコード/アプリケーションはすべて、エンティティとしてアドレスデータを持っています。そのDBテーブルには独自のIDがあります。システムがすべてのビジネス活動/イベントが発生するすべてのアドレスを把握したい場合は、意味をなさないでしょう。しかし、私はこれらのサンプルコード/アプリケーションでこのような意図は見られません。私は何かを見逃していますか？

Answer 1

一般化することはできません。

例は実際の問題とは別のものです。あなたはすべてのプロジェクトに対して、それがすべてのものに合っているとは言えません。

私は、集計根を保存しているプロジェクトの例を挙げます。論理的および法的に子会社は、その会社の拡張です。ウォルマートは、実際のものが販売されている税番号のないHQ、税金番号のないすべてと子会社を持っています。論理的には、政府の資金調達などに適用するために、HQはその子会社に依頼します。ここでは、ウォルマートHQは総額のルートであり、その子会社は資金調達手続きの集合体の一部です。 これは論理的な例です。

私が持っていたことは、子会社がHQの知識なしに州の資金調達を法的に申請できることです！そのため、HQはもはや集約ルートではありませんが、子会社があります。それは非常に非論理的でしたが、それはビジネス要件でした。

ポイントは、値オブジェクトの質問と同じです。 Addressはエンティティまたは値オブジェクトであることを例として使用できますが、アドレスが何であるかを指定するのはビジネスの要件であり、論理的なものは必要としません。

Answer 2

プレノート：アドレスがメールサービスのようなエンティティであるべきドメインがあります。私たちはそれらのドメインについては話しません

私の経験から、永続性のためにアドレスをサブエンティティとしてリレーショナルデータベースに保持する方が簡単です。ストレージテーブルの主キーとして機能するエンティティIDのため

しかし、値オブジェクトをデータベースエンティティとして保存することはできますが、そのまま値オブジェクトとして使用することができます。 Vaughn Vernonは、彼の方法でこれを行う方法を示します。book、第6章、サブチャプター持続値オブジェクト。