ドメインオブジェクトはJPAエンティティと同じですか？値オブジェクト（例えば、ドル建ての請求書）がある場合、データオブジェクトを参照オブジェクトとしてデータストアに格納するにはどうすればよいですか（またはそれを行う必要がありますか）。ドメインオブジェクトはJPAエンティティと同じですか？
場合によってはエンティティであるドメインオブジェクトとその他の場合には値オブジェクトの微妙な違いは何ですか？誰も私にこのことに関する良い紙を教えてもらえますか？
「ドメインオブジェクト」は、より概念的な用語です。 「JPAエンティティ」とは、ドメインオブジェクトを実装するのに役立つ特定のテクノロジを指します。
通常、ドメインオブジェクトは、ドメイン内の名詞（注文、請求書、顧客など）に対応します。通常、これらは純粋なデータ転送オブジェクトではなく、データベースに近いものとして認識されます。たとえば、ドメインオブジェクトの実装に使用するクラスでORMアノテーションが表示されることがあります。
多くの人がドメインオブジェクトを貧弱な方法で実装しています。ほとんどはORMマッピングを持つプロパティですが、ドメインオブジェクト自体には実際のロジックはありません。彼らはドメインサービスにロジックを置きました。
一方、ドメイン駆動設計の提案者は、ロジックをドメインオブジェクトに置きます。
どちらの方法でも、これらはシステムのドメインオブジェクトです。
JPAエンティティは、@Entity、@Column、@ManyToOneなどでアノテーションを付けたクラスです。これは、ドメインオブジェクトを実装する方法です。上記のように、ドメインロジックをオブジェクト自体に配置することもできます。
ドメインドリブンデザインのコンテキストでは、それらは同じではありません。ドメインオブジェクトは、エンティティと値オブジェクトを含む集約であり、永続性を無視する必要があります。したがって、JPAアノテーションを含むべきではありません。
いいえ、ドメインオブジェクトは、ビジネスの関連する概念を表し豊富な振る舞いを持つオブジェクトです。 JPAエンティティは永続性の技術的解決策です。
ドメインオブジェクトはJPAエンティティと同じですか？
いいえ、そうではありません。
Iは、基準オブジェクトとしてデータストア内の値オブジェクト（例えば、ドル紙幣）、どうすればよい（あるいはべきI）店を持っていますか？
私は@Embeddableを使用して値オブジェクトを格納お勧めします。 VOは（彼らは親と同じテーブルに格納されている）あなただけの親からそれらへの参照を持つべきで、@Idは必要ありません。コレクションの場合、@ ElementCollectionを使用します。
@Emedded値オブジェクト休止状態でより良い実行されます。
他の例では、いくつかの例では、エンティティと値オブジェクトというドメインオブジェクトの機微は何ですか？
エンティティは、@Idによって区別されるオブジェクトです。反対に、値オブジェクトは値によって区別されます。バリューオブジェクトはしばしば不変として実装されますが、エンティティ/ドメインオブジェクトはその状態を変更するビジネスロジックを含みます。
一部のビジネスケースでは、別の集計に渡すか、ドメインイベント内で公開する、値オブジェクト（別名スナップショット）としてのドメインオブジェクトの表現が必要です。
誰も私に良い紙を教えてもらえますか？
予約：Vaughn Vernonのドメインドリブンデザインを実装する。
はい、JPAエンティティと同じドメインオブジェクト – James
ドメインオブジェクトは「貧血」オブジェクトではなく堅牢になる傾向があるため、ドメインドリブンデザイン環境ではそうではありません。 http://stackoverflow.com/questions/5589141/understanding-domain-objects-services –
ドメインロジックをエンティティに置くのを止めるのはなぜですか？最初の場所でテーブルの行を実際のオブジェクトにマッピングするのは、全体のポイントではありませんか？それ以外の場合は、HashMapsを使用してテーブルの行からデータを表すこともできます。 – wrschneider