JPA Clean Architecture

Question

I'm refactoring a microservice according to Clean Architecture:

Frameworks should be at the utmost layer. So I used the Adapter Pattern and Dependency Inversion to put org.springframework.data.repository.CrudRepository at the utmost layer. But how can I use @Entity (from Java Persistence API) to persist my entities, if entities are in the center and frameworks are at the utmost layer?

---

Example: Demo-Entity:

import javax.persistence.Entity;
import javax.persistence.Id;
import javax.validation.constraints.NotNull;

@Entity
public class Demo implements Serializable {
    @Id
    @GeneratedValue
    private long id;
    
    @NotNull
    private String foo;

}

GenericRepostioryInterface (in the Usecase Layer)

public interface CrudRepositoryInterface<S,T> {
    public <U extends S> U save(U u) ;    
    public <U extends S> Iterable<U> saveAll(Iterable<U> itrbl) ;    
    public Optional<S> findById(T id) ;    
    public boolean existsById(T id) ;    
    public Iterable<S> findAll() ;    
    public Iterable<S> findAllById(Iterable<T> itrbl) ;    
    public long count() ;    
    public void deleteById(T id) ;    
    public void delete(S t);    
    public void deleteAll(Iterable<? extends S> itrbl) ;    
    public void deleteAll() ;  
}

Some usecase:

    @Autowired
    private CrudRepositoryInterface<Demo,Long> demoRepository;
    ...
    
    private void deleteAll(){
      this.demoRepository.deleteAll();
    }
    ...

Adapter (DB Layer)

public interface DemoRepositoryAdapter extends CrudRepository<Demo,Long>,CrudRepositoryInterface<Demo,Long>{    
}

Config for Injection (I put that in the DB Package/Layer as well)

@Configuration
public class InjectRepositoryConfig {    
    @Bean
    public CrudRepositoryInterface<Demo,Long> animalOwnerRepository(@Autowired DemoRepositoryAdapter demoRepositoryAdapter){
        return demoRepositoryAdapter;
    }
}

---

This works fine so far but I'm unsure how to remove / replace / refactor JPA out of the core layer?

Answer 1

I think the general confusion here is due to the overloading of the term Entity, which has different semantics across different contexts. In the context of JPA, an Entity is a persistence abstraction representing rows in a table and ORM. In the context of Clean Architecture, an Entity is a business domain abstraction and is completely independent of persistence.

They can co-exist in a Clean Architecture, but they each serve distinct purposes. Attempting to combine them and leverage JPA capabilities in your business domain entities violates the principles of Clean Architecture and will couple your domain to your persistence implementation.

Answer 2

If you really want to follow clean architecture, then no reference to external libraries should be in your domain classes. To overcome that, a couple of strategies could be:

• User jpa/hibernate XML mappings. This way you can externalize your mappings and change between sql/noSql easily just importing a different config file (each file will setup a different set of XML mappings).

The downside of this approach, is that your domain will still require to implement Serializable, and most of them will require setters/getters for its fields, or force hibernate/jpa to ignore Java limitations and access private fields. Also, there are things you can do with Annotations that is not possible with XML, or the workaround is problematic. It works, but still your domain layer looks like simple DTOs.

• When crossing a boundary, use DTO objects. This means you will have your domain object Demo, and a DTO object DemoData for example. Data will be retrieved using DemoData instances, and repository should convert between those two when saving/retrieving.

This last approach makes you project very easy to change. You can change persistence layer any time, but doing so will require a whole new datastore layer to integrate. Let's say you want to change to cassandra, you will need a new DTO DemoDataCassandra, its mappers between it to Demo, new annotations for mappings, etc.