L'architettura del progetto ha una forte relazione con le biblioteche usate?

Question

Programmatori, quando si tratta di parlare di modelli popolari nelle applicazioni aziendali, predicano che dovresti codificare contro le interfacce per rimuovere le relazioni forti tra i componenti; Ciò aiuterà a cambiare i tipi concreti minimizzando al contempo i cambiamenti in altre aree dell'applicazione. Il presupposto sottostante è che le interfacce riguardano le astrazioni. Quando si tratta di vita reale è quasi impossibile. Usiamo un esempio:

Supponiamo che tu attualmente utilizzi un framework ORM nella tua applicazione, che hai astratto applicando il modello di repository. Ora, puoi davvero cambiare il framework ORM senza soluzione di continuità?

public interface IRepository<T>
{        
    T GetById(int id);      
    void Add(T entity);
    void Remove(T entity);
    void Update(T entity);
    IQueryable<T> Query(Expression<Func<T, bool>> filter);                                
} 

Teoricamente, questa implementazione può essere applicata al resto dell'applicazione, ma rimangono molte domande sull'effettiva applicazione di questo modello:

1. In che modo questo modello mi protegge dal processo interno delle librerie?
2. In che modo l'astrazione affronta la variazione delle eccezioni lanciate da ciascuna biblioteca?
3. Se ho selezionato un ORM che fornisce un meccanismo di memorizzazione nella cache internamente e in seguito decido di passare a un ORM alternativo senza tale supporto, in che modo il modello gestisce questo?

Quindi, da questo, credo che l'architettura del progetto sia fortemente influenzata dalle biblioteche che vengono utilizzate. c'è qualcosa di sbagliato con questo? Sto assumendo troppo da questo schema?