Onion Architecture using JPA Entity as Domain Entity

Question

I've been struggling to choose to work with JPA entities as separated classes than domain entities in a single bounded context. I've faced the following choices

Use separated domain classes for Aggregate roots/Aggregates..etc with domain repositories to wrap Spring JPA repositories and use converters to map JPA entities <> Domain Entities with only required data

• Lazy loading is about to be given away unless in mappers/converters are handling this inside domain repositories but this is overkill.

• When saving objects, there might be related Aggregate roots (one to many relationship) which later in complex logic, I had to extremly take care of the state of the Domain entity to pass it to the domain repository and either fill it with all related data or simply map it (another method in the converter) with out relationship data (cascading not applied on JPA persisting)

• A lot of duplicated code to avoid such situations even for very simple use cases

Or Use JPA entities as my domain entities and so far there are multiple examples/opinions of this like

https://github.com/citerus/dddsample-core/tree/Spring_Annotations_Autowire

http://www.javamagazine.mozaicreader.com/MayJune2018/Twitter#&pageSet=50&page=0

Should JPA entities and DDD entities be the same classes?

DDD, domain entities/VO and JPA

How to implement DDD using Spring Crud/Jpa Repository

On the other hand, there are opinions like this

Is it a good practice to use JPA entities as domain models?

My question, on the long run, from experience

• What would cost more effort & time ?
• Are both approaches are acceptable as practices ?
• What are the pros and cons of both ?

Answer 1

What would cost more effort & time ?

Decoupling almost always does. It's trade-off !

Are both approaches are acceptable as practices ?

Yes. I see there are many conflicted opinions on both approaches but really, they're just opinions. Both are applied and cost.

What are the pros and cons of both ?

Using JPA entities as domain entities approach really 1- reduces the time cost notionally. 2- Also lets you use lazy loading with relationships avoiding more code in application service, that if you're not following referencing other aggregates by id instead which also is opinion based but really costs the lazy loading of JPA.

One down side to this approach is unit testing as I see it. Unit test should not depend on starting up container, database...etc. Should purely test business logic. But that's not optimally possible with such frameworks. See this answer for example

JPA Entity must be unit tested and how?

Using JPA as separated entities in the infrastructure with wrapper repositories will make unit tests easier to mock data and test purely the domain (business rules) with comfort. It will reversely to the previous pros, cost you the mapping effort and time, too much duplicated code for mapping, wrapping repositories..etc. It brings the headache (and this should be a pro) of caring what is the state of your domain entity because mapping of nulls to JPA entity will effect the relationships mapping to your persistence source, and you REALLY SHOULD CARE for the state of your domain entity.

Also automatic lazy loading of ORM will not be used and done easily. Either

1- You put a reference to other aggregates as member in your aggregate root (Breaking the aggregate ID reference rule) and handle that in the mappers

2- You get from repository only wanted data of aggregate root with other aggregate's ID as reference members. This is done by well defined queries in the repository implementation so, this is a lot of writing & customizing queries. Avoiding using default ones which returns full JPA entities with ready lazy loading related references.