L'implementazione di Spring Data Repository viola il principio dell'accoppiamento lento?

Così, al momento mi trovo a costruire la mia struttura di c#/.net (web) (o cartella / progetto / pacchetto -...) spesso come questa, ripensandoci in un "modo un po 'cipolla-architettonico":

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.

In realtà, mi piace molto avere questa separazione, dandomi una buona panoramica su:

• ciò che è realmente "di valore" al momento (all'interno di Domain.Model)
• che cosa è solo "presentazione dei dati" (API)
• che cosa sono "Le dipendenze circostanti che possono cambiare" (Infrastruttura)

Quindi, inizierò un nuovo lavoro tra qualche settimana, tornando al mondo java e faremo un uso massiccio di spring (boot / cloud) per creare una nuova applicazione. Per questo motivo, penso a utilizzare l'ORM hibernate standard del settore, ma inoltre ho trovato molto utile avere un OR-Mapper leggero come JDBI. E in realtà leggo molto sul fatto che Hibernate è lento su larga scala e conosco lo stesso comportamento quando si tratta di entità Framework.

Ora cerco gli esempi di avvio di Spring e ricordo che non è necessario utilizzare un'implementazione di un repository per utilizzare effettivamente il repository utilizzando Spring Data.

Una tipica implementazione di Spring Repository potrebbe essere simile a questa:

Public interface PersonRepository extends CrudRepository<Person, Long> {

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

Quindi, mi sto chiedendo dove mettere questa interfaccia ora? A prima vista, lo inserisco nel mio pacchetto Domain.Model come Interfaccia Repository. Ma non molla "in background" crea un'implementazione effettiva all'interno (!) Del mio dominio.model, quindi, accoppiandolo così con una tecnologia di persistenza, un OR-Mapper e così via?

In .NET, in realtà creo semplicemente un semplice I [Class] Repository all'interno del mio dominio e aggiungo l'effettiva implementazione nella mia Infrastruttura, come Entity Framework o Dapper. Questo mi consente di cambiare facilmente OR-Mapper, anche l'intero DBMS. Quindi, farlo in primavera comporterebbe la creazione di una tonnellata di codice boilerplate per le operazioni CRUD, perché non posso usare l'interfaccia CrudRepository o ho sbagliato qui?

Quindi, sarebbe meglio semplicemente creare un "semplice" repository all'interno del mio dominio.model? Ma non sarebbe solo l'inizio per la tonnellata di boilerplatecode che in realtà voglio evitare?

Forse non dovrei "lavorare contro il framework" qui, perché, in ultima analisi, dovrei farlo anche per ogni altro Call per le spring components, quando voglio essere al 100% con conseguente astrazione del mio dominio dalla tecnologia attuale ..?

Sono un po 'perso qui, in questo momento mi sembra davvero un nodo in testa. Forse mi manca anche qualcosa di ovvio.

Spero che tu possa darmi dei consigli chiarendo come funziona l'implementazione del repository Spring e perché è giusto averlo all'interno di Domain.Model, o mostrarmi il mio malinteso strutturale mentre mi dà consigli su una struttura migliore per i miei progetti.

Grazie in anticipo!