Does the Spring Data Repository implementation violate the principle of loose coupling?

Question

So, at the moment I find myself building my c#/.net (web) application ( or folder/project/package-...) structure often like this, thinking about it in a "somewhat onion-architectural way":

myApp
    - API
        - Controllers for HTTP, REST etc., may even be a whole gui, though ...
    - Domain.Model
        - "Business Logic" for the actual application, being most 
           of the time a (micro)service...
        - Interfaces for Repositories, Thirdparty(see below)...
    - Infrastructure
        - ThirdParty
            - Call to other Services,
        - Persistence
            - Implementations for Repositories
        - Adapters
            - Adapt some Class to a DTO for my domain 
    - Config
        - global configurations...
    - Tests
        - empty... just kidding.

Actually, I like to have this Separation a lot, giving me a good overview about:

• what is really "of value" at the moment (inside the Domain.Model)
• what is just "presenting the data" (API)
• what are "The surrounding, may-be-changing dependencies" (Infrastructure)

So, I'm going to start a new job in a few weeks, going back to the java world and we'll make heavy use of spring (boot/cloud) to create a new application. For thus, I think about using the industry-standard hibernate-ORM, but besides, I found it very helpful to have a lightweight OR-Mapper like JDBI, too. And I actually read a lot about Hibernate being slow at scale, and I know the same behaviour when it comes to entity Framework.

Now I look for Spring boot examples, and I remember one does not need to use an Implementation of a Repository to actually use the repository using Spring Data.

A typical Spring Repository implementation might look like this:

Public interface PersonRepository extends CrudRepository<Person, Long> {

  List<Person> findByEmailAddressAndLastname(EmailAddress emailAddress, String lastname);
  ...
}

So, I'm asking myself where to put this interface now? At first glance, I'd put it into my Domain.Model package as the Repository Interface it is.But doesn't spring "in the background" create an actual implementation inside(!) my domain.model, then, thus coupling it to a persistence technology, an OR-Mapper, and so on?

In .NET, I actually just create a simple I[Class]Repository inside my domain, and add the actual implementation in my Infrastructure, like Entity Framework or Dapper. This allows me to very easily switch OR-Mappers, even the whole DBMS. Thus, doing it like this in Spring would result in creating a ton of boilerplate-code for CRUD operations, because I can't use the CrudRepository Interface, or am I wrong here?

So, would it be better to just create a "plain" Repository inside my domain.model? But wouldn't that be just the start for the ton of boilerplatecode I actually want to avoid?

Perhaps I should just not "work against the framework" here, for in last consequence, I'd have to do it for every other Call to spring components, too, when I want to be 100% consequent in abstracting my domain from the actual technology..?

I'm a bit lost here, it actually feels like a knot in my head at the moment. Perhaps I'm even missing something obvious.

I hope you could give me advice by either clarifying how the spring repository implementation works and why it is okay to have it inside Domain.Model, or showing me my structural misconception whilst giving me advice to a better structure for my projects.

Thanks in advance!

Answer 1

tl;dr

Does the Spring Data Repository implementation violate the principle of loose coupling?

No. Since there is no coupling with only defining an Interface.

---

Long version

I) According to your project layout - and your intentions in doing it so - you are tying to achieve separation of concerns (trying to separate tiers roughly with API, Domain / Model and Infrastructure as you call it). Besides there are tests and configuration.

The Three-Tier-Architecture separates between presentation tier, middle tier and data tier. You have two distict tiers, namely responsible for presentation and persistence and "things in the middle".

So from an architectural point of view, the interface declaration either belongs to the "lower end" of the middle tier as it communicates with the data layer:

Mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects.

from Patterns of Enterprise Architecture

or you could put it in the "upper end" of the data tier as in this Picture. Anyways it is distict from the domain objects.

A first step to improve your design would be to put the interface definitions from your Domain-Folder to the Infrastructure - Folder

II) If you take a look at how Spring Data works you find, that in order to activate the magic one has to declare @EnableJpaRepositories("com.acme.repositories").

This allows me to very easily switch OR-Mappers, even the whole DBMS.

You could do this with Spring as with Entity framework.

then, thus coupling it to a persistence technology, an OR-Mapper, and so on?

No. You just conigure the container to choose one "implementation"; but that's not coupling. You are free to provide your own.