El acceso a datos en arquitectura limpia sigue siendo un pilar de cualquier aplicación, aunque la base de datos deje de ser el centro del diseño. Aquí entenderás por qué conviene moverla a la capa de infraestructura, qué fuentes de información entran en juego y cómo esa decisión te facilita las pruebas. Es una guía pensada para desarrolladores que vienen de MVC o de la arquitectura de tres capas y quieren dar el salto a un enfoque más flexible.

¿Por qué sacar la base de datos a la capa de infraestructura?

La duda aparece casi siempre: si ya tengo mi motor relacional, ¿para qué complicarme separándolo? La respuesta corta es que el acoplamiento directo te limita más de lo que crees [0:50].

Un argumento clásico es la portabilidad entre motores: hoy uso SQL Server, mañana migro a MySQL o Postgres. Suena bien, pero en la práctica casi nadie cambia de base de datos con frecuencia. Es costoso a nivel de infraestructura y de desarrollo, y el dialecto de SQL varía entre motores, así que lo que corre en uno puede romperse en otro [2:10].

¿La razón principal para separar la base de datos es poder migrar de motor? No. Las migraciones reales son la excepción. La verdadera razón es que tu sistema rara vez depende de una sola fuente de datos y necesitas poder probarlo sin levantar toda la infraestructura.

¿Cuáles son las fuentes de datos más comunes en una aplicación moderna?

Pensar que toda la información vive en una sola base de datos relacional es irreal. En entornos interconectados, tu sistema suele leer y escribir desde varios lugares.

Bases de datos de legado y sistemas antiguos

Cuando construyes un sistema nuevo dentro de una empresa, lo normal es que existan aplicaciones previas con las que tienes que integrarte. A veces te conectas directamente a sus bases de datos porque la información no se ha podido migrar al nuevo modelo [3:30]. Tu base de datos puede estar perfectamente organizada, pero igual vas a leer datos de un sistema viejo que sigue operando.

Archivos como fuente de información

No todo está en tablas. Mucha información circula en archivos XML, JSON u hojas de cálculo, sobre todo cuando los usuarios manipulan esos documentos a mano y no existe una interfaz intermedia [4:40]. Tu aplicación tendrá que leerlos y, en algunos casos, escribirlos.

Sistemas de terceros: CRM, ERP y motores de búsqueda

Un CRM, un ERP o cualquier herramienta SaaS que use el equipo se convierte en fuente de datos. No es una base de datos como tal, pero sí un origen del que extraes o hacia el que envías información para mantener todo sincronizado [5:20].

Los motores de búsqueda como Algolia o Elasticsearch entran en la misma categoría. Sincronizas datos hacia ellos para que el usuario consulte rápido sobre grandes volúmenes, aunque la fuente original siga siendo otra [6:00].

¿Qué cuenta como fuente de datos en una arquitectura limpia? Cualquier origen del que tu aplicación lea o al que escriba: bases de datos relacionales, archivos JSON o XML, APIs de terceros, CRMs, ERPs y motores de búsqueda como Elasticsearch o Algolia.

¿Cómo facilita las pruebas separar el acceso a datos?

Aquí está la razón más fuerte para mover la base de datos a la infraestructura: poder probar bien tu lógica de negocio. Cuando esa lógica está acoplada al acceso a la base de datos, el testing se vuelve un dolor de cabeza [6:40].

Para probar necesitas:

• Una base de datos disponible que no sea la de producción.
• Información cargada y relevante para cada caso de prueba.
• Mantener ese entorno limpio entre ejecuciones.

Si en cambio defines una interfaz para el acceso a datos y la implementas en la capa de infraestructura, puedes sustituir esa implementación por objetos especiales durante las pruebas. Eso hace que los tests corran muchísimo más rápido y sin depender de un motor real [7:30]. La idea de usar objetos sustitutos para aislar dependencias es un recurso central del diseño orientado a pruebas, y se apoya en el principio de inversión de dependencias que ya viste en módulos anteriores.

El siguiente paso: el patrón Repository

Lo que sigue es darle forma concreta a estas ideas con el patrón Repository, que estructura el acceso a fuentes de información detrás de una interfaz clara y consistente. Ahí vas a ver cómo conectar la teoría con código real.

¿En tu proyecto actual cuántas fuentes de datos distintas conviven? Cuéntame en los comentarios cuál te ha dado más problemas a la hora de separar la lógica.