DDD Entity in orm and java

Question

I started reading chapter 5 of E. Evans DDD and try to make head or tail of the concepts.

In context of ddd what is and what is not entity and what is value object ?

looking at Value object or entity object in my Hibernate mapping? - but it is about Hibernate, not DDD, I ask about DDD

1. In above sample of hibernate OrderLine is Entity, but is OrderLine still a DDD entity ?
2. And more generally, can we say that any jpa/Hibernate @Entity is DDD entity, or not ?
3. It seems to me, that OrderLine is a good example of Jpa/Hibernate entity that is not a DDD entity, is it ?

If we for instance had used some object database we would possibly store Order togeter with it's OrderLines, wouldn't we ?

4. In terms of relational databases could we say, that Jpa @Entity that is mapped in database as OnDeleteCascade is not a DDD Entity, but it is still a value object ?
5. Is hibernate @Embedded always a DDD value object ? (seems yes, it has no identity)

Ok, and now other case with other doubts. Lets say that we have two different systems one in Java other in Python. One for billing other for marketing. Both of them have a Customer Entity.

6. Do we say that BillingCustomer is the same DDD Entity as MarketingCustomer (assuming both of them represent the same Customer John Doe born 01.01.1980 wiht ssn 12-34-56)? This would imply that in java two different classes, even not having common parent (except from Object) can represent the same DDD entity. If so, how should equals be implemented in above classes ?
7. Should java equals return true for two different java classes representing the same DDD entity ?

It is often written that Entities are mutable and value objects are immutable.

8. How would we implement below with java and hibernate :

   @Entity Person has @Embedded Address, Person class has getters and setters and Address only getters ? And to change address street we would do sth like person.setAddress (Address.builder(person.getAddress()).setStreet("newStreet").build()) ?

Answer 1

Looking for an objective answer to all those might be difficult as there are multiple conflicting interpretations.

Generally though, DDD Entities and Value Objects have some resemblance to ORM Entities and Values, but they are very distinct concepts. The two main reasons being:

• The "identity" referred to in both are different. Database things have database-related identity which rarely if ever matches to business-related identities, especially when denormalized.
• ORM and Persistence in general is a technology and has nothing to do with "business".
• DDD Entities and Value Objects are Objects not Data. With that I mean that they should generally conform to Object-Oriented principles, one of which is that Objects should be concerned with behavior not data. This usually leads to completely different forces being applied to them.

Because of these points, and there might be others, ORMs should never be mixed into "real" business objects.

So with all that in mind, let's answer your questions:

1. No, a Hibernate Entity should never be a DDD Entity.
2. Not, JPA/Hibernate Entity should never be a DDD Entity.
3. Correct.
4. No, JPA Entities/Value Objects have no direct relation to DDD Objects.
5. No, no relation.
6. No, objects' identity can refer to pure conceptual things. BillingCustomer and MarketingCustomer are conceptually different things, so they would never equal, even though the "real" human behind them is the same. In general "real" has a different meaning in software designs. We consider everything "real" that is part of the business (i.e. part of the Ubiquitous Language), even if some or even most of it is not "real" in the conventional sense.
7. No, equals() should also conform to normal Java rules. Objects of different classes should never equal. It would be extremely confusing. Define another relation, for example matches(), or sameCustomer(), etc.
8. Don't know what you mean.

HTH.