Dirección de las dependencias
Hacia dónde apunta una flecha en un diagrama de dependencias: hacia la abstracción estable, no hacia el detalle concreto que la llame.
La dirección de las dependencias trata de qué lado de una relación tiene permiso para obligar al otro a cambiar. Dos piezas de código que interactúan no son automáticamente iguales: una de ellas nombra a la otra, la importa, conoce su forma. Esa depende de la otra, y es la que se rompe primero cuando la otra cambia.
La dirección ingenua suele seguir el flujo de control. Una regla de negocio que llama directamente a la base de datos "depende" de ella en el código: importa el driver, construye la query, conoce el esquema. Eso es justo al revés de lo que de verdad importa. La regla de negocio es la parte que merece la pena proteger; la base de datos es un detalle sustituible. Hacer que la regla dependa directamente de ella significa que cada decisión sobre almacenamiento se filtra hasta el sitio que debería ser el más estable.
Invertirla no cambia lo que pasa en tiempo de ejecución, la base de datos se sigue llamando. Cambia quién tiene permiso para obligar a cambiar a quién. Los dos lados pasan a depender de una interfaz: la regla define la forma que necesita, y la base de datos la implementa.
Esa es toda la idea detrás de la inversión de dependencias: no eliminar la dependencia, solo apuntarla hacia algo lo bastante estable como para merecer la pena depender de ello.