Should JPA entities and DDD entities be the same classes?

Question

There are classes that are entities according to DDD, and there are classes that have @javax.persistence.Entity annotation. Should they be the same classes? Or should JPA entities act just as a mechanism for a mapper (https://martinfowler.com/eaaCatalog/dataMapper.html) to load DDD entities from a database (and store them) and be kept outside the domain model?

Would it make a difference if database metadata were separated and stored externally (for example, in XML)? If such classes are entities, where is the boundary? I think classes generated from XSD (for example, with JAXB) or even from database with MyBatis Generator are not entities as understood in DDD.

Bega

Related: #26739506 – Stefaniastefanie

Related: #31400932 – Stefaniastefanie

Answer 1

That's an implementation detail really. They could be or they could not depending on the flexibility of your ORM. For instance, if your ORM allows to map your domain objects without polluting them with persistence concerns then that's the approach that requires the less overhead and which I'd go for.

On the other hand, if your ORM is not flexible enough then you could go for a pragmatic hybrid approach where your AR and it's state are two different classes and where the state class is simple enough to easily be mapped. Note that the AR would still be responsible to protect it's state here and the state object wouldn't be accessed directly from outside the AR. The approach is described by Vaughn Vernon here.

Travelled

Thanks for your superb answer! AR == Aggregate root, I assume. I haven't read VV's books yet. So it must be all right if JPA entities are treated as plain DTOs hiding behind AR. And should we have not more than one AR class for the same graph of DTOs in such case? – Bega

Answer 2

Your JPA entities should be the domain entities. Why? Your domain entities should express some strong constraints, e.g. by

• Having parameterized constructors
• Not exposing all setters
• Do validation on write operations

If possible, a domain entity should always remain a valid business entity. By introducing some kind of mapper, you introduce a possibility to automagically write arbitrary stuff into your domain entities, which basically renders your constraints useless.

The other option would be enforcing the same constraints on JPA and domain entities which introduces redundancy.

Your best bet is keeping your JPA entities as ORM-agnostic as possible. Using Hibernate, this can be done using a configurating class or XML file. But I am no Java EE/JPA guy, so it's hard for me to give a good implementation advice.

Steer

Answer 3

After some more experience with JPA and microservices, I would say that I would most likely not separate them when using JPA, unless there's a reason that makes me do otherwise. On the other hand, entities in a single bounded context do not necessarily have to be only JPA entities. It's possible to have both entities mapped by JPA implementation and entities mapped from DTOs using other technologies (like JSON mappers) or manually.

Bega

Answer 4

I agree that both ways are possible. After programming some applications with DDD in mind, I find that this heuristic works well:

• If you start from having an entity and not having JPA, it will probably be too hard to refactor an entity so that it can be used by ORM framework, so keep them separate
• If you start from scratch, it is worth not distinguishing DDD entities from JPA entities

Bega