1

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 ?

  1. 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 ?
  2. 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.

  1. 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 ?
  2. 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.

  1. 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()) ?

bastiat
  • 1,799
  • 2
  • 19
  • 38
  • Possible duplicate of [Should JPA entities and DDD entities be the same classes?](https://stackoverflow.com/questions/46227697/should-jpa-entities-and-ddd-entities-be-the-same-classes) – guillaume31 Aug 01 '18 at 11:25
  • This is probably both too broad and duplicate of many questions that were already asked before. – guillaume31 Aug 01 '18 at 11:29

1 Answers1

5

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.

Robert Bräutigam
  • 7,514
  • 1
  • 20
  • 38
  • I totally agree with your answer. However, how do you map one-to-many relations in the repository implementation with an ORM in case of updating the aggregate? How do you know which child entities are new and which ones are updated? Child entities typically don't have a business-id, they only have a primary key in the db pointing to the parent. A child entity in DDD 'should not' expose a primary key. So how do you detect changes in a collection which need to be propagated to the DB via some ORM? – user2054927 Apr 30 '20 at 11:59
  • The problem you describe is simply a problem of ORMs, not of DDD nor OO. You try to apply a change, which because of the ORM you are forced to apply onto an in-memory copy of your DB essentially. This data-model is usually not capable of telling you what changed afterwards, hence your problem. If the ORM wasn't there, you could apply that change directly to the DB, record the change itself in some other, more suitable data model, collect it into a transaction, etc. I guess what I'm saying is ORMs are surprisingly often unsuitable even for simple use-cases. – Robert Bräutigam Apr 30 '20 at 12:31