Question

Are domain objects the same as JPA entities? If I have a value object (e.g. a dollar bill), how can I (or even should I) store that in the datastore as a reference object?

What are the subtleties of domain objects being entities in some cases and value objects in other cases? Could anyone direct me to a good paper on this?

Was it helpful?

Solution

"Domain object" is a more conceptual term; "JPA entity" refers to a specific technology useful for implementing domain objects.

Generally domain objects correspond to the nouns (orders, invoices, customers, etc.) in your domain. Usually we see these as being closer to the database rather than pure data transfer objects. So you might see ORM annotations on the classes you use to implement your domain objects, for example.

A lot of people implement domain objects in an anemic way--mostly properties with ORM mappings, but no real logic on the domain objects themselves. They put the logic in domain services.

On the other hand proponents of domain-driven design put the logic on the domain objects.

Either way these are the domain objects in your system.

JPA entities are classes that you annotate with @Entity, @Column, @ManyToOne, etc. This is a way to implement domain objects. You may decide to put domain logic on the objects themselves, as noted above.

OTHER TIPS

In the context of Domain Driven Design, they are not the same. A domain object can be an aggregate that contains entities and value objects and should be ignorant of persistence. Thus, it should not contain any JPA annotations.

No, Domain Objects are objects with rich behaviour that represents a relevant concept of the business. JPA entities are a technical solution to persistence.

Are domain objects the same as JPA entities?

No, they are not.

If I have a value object (e.g. a dollar bill), how can I (or even should I) store that in the datastore as a reference object?

I recommend storing Value Objects using @Embeddable. VO don't need @Id, you should only have reference to them from parent (they are stored in the same TABLE as parent). In case of collections use @ElementCollection.

@Emedded Value Objects performs better in Hibernate:

  • you do not have JOINS if you are not using @OneToOne.
  • Value Object collections can be removed with one DELETE and do not have to be loaded before deletion.

What are the subtleties of domain objects being entities in some cases and value objects in other cases?

Entities are objects that are distinguished by @Id, on contrary Value Objects are distinguished by values. Value Objects are often implemented as immutable, whereas entites/domain-objects contain businness logic that mutate its state.

In some business cases you need representation of Domain Object as Value Object, aka Snapshot, that you for example pass to another Aggregate or publish inside Domain Event.

Could anyone direct me to a good paper on this?

Book: Implementing Domain-Driven Design, Vaughn Vernon.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top