Cuando trabajamos con arquitecturas limpias, una de las preguntas más frecuentes es por qué tomarse el trabajo de separar el acceso a datos hacia la capa de infraestructura. La respuesta va mucho más allá de la típica razón de "migrar de base de datos", y entender esto cambia por completo la forma en que diseñamos nuestras aplicaciones.
¿Por qué migrar de base de datos no es la mejor razón para separar?
El ejemplo clásico que suele darse es el siguiente: si tienes una interfaz y una clase conectada a SQL Server, el día que quieras cambiar a MySQL o PostgreSQL, simplemente creas otra implementación y listo. Aunque esto es técnicamente posible, no es la razón principal para hacer esta separación [0:52].
La realidad es que uno no cambia de base de datos con frecuencia. Existen casos reales, pero son más la excepción que la regla. Una vez que se toma una decisión de diseño sobre qué motor utilizar, se suele mantener porque el cambio es costoso:
- A nivel de infraestructura requiere reconfiguración completa.
- A nivel de desarrollo implica adaptar diferencias entre motores.
- El estándar SQL tiene variaciones de un motor a otro, lo que significa que lo que funciona en una base de datos puede no funcionar igual en otra [1:30].
¿Cuáles son las verdaderas fuentes de datos en una aplicación moderna?
La razón más sólida para separar el acceso a datos es que la base de datos relacional no es la única fuente de información [1:52]. En aplicaciones cada vez más interconectadas, los datos pueden provenir de múltiples orígenes.
¿Qué rol juegan las bases de datos de legado?
Cuando construyes un sistema nuevo dentro de una empresa que ya tiene otras aplicaciones, es probable que necesites integraciones con sistemas existentes [2:05]. A veces esos sistemas son antiguos y no han podido migrarse por completo. Esto significa que tu aplicación puede tener una base de datos nueva y bien estructurada, pero al mismo tiempo necesitar conectarse a otra base de datos heredada para acceder a información que aún no se ha migrado.
¿Por qué los archivos también son fuentes de datos?
En muchos proyectos la información se almacena en formatos como:
- Archivos XML.
- Archivos JSON.
- Hojas de cálculo.
Estos archivos funcionan como fuente de datos tanto para lectura como para escritura [2:44], especialmente cuando son manipulados directamente por los usuarios y no existe una interfaz que los guarde en un almacenamiento más estructurado.
¿Cómo se integran sistemas de terceros y motores de búsqueda?
Los sistemas de terceros como un CRM o un ERP también se convierten en fuentes de datos para tu aplicación [3:07]. No son una base de datos en el sentido tradicional, pero necesitas integrarte con ellos para extraer, enviar y sincronizar información.
Otro ejemplo relevante son los motores de búsqueda como Algolia o Elasticsearch [3:33]. En cierto tipo de aplicaciones se implementan para que las consultas sean mucho más rápidas sobre grandes conjuntos de datos. La información que el usuario consulta no viene directamente de la base de datos, sino de estos motores donde se sincroniza previamente.
¿Cómo mejora la separación de datos la capacidad de hacer testing?
La segunda razón de peso para separar el acceso a datos hacia la infraestructura es poder probar correctamente la lógica de negocio [4:06]. Cuando esa lógica está fuertemente acoplada al acceso a base de datos, el testing se vuelve extremadamente difícil.
Sin esta separación, para ejecutar pruebas necesitarías:
- Una base de datos lista y preparada, que nunca debe ser la de producción.
- Información relevante cargada previamente para cada escenario de prueba.
- Configuración adicional que ralentiza todo el proceso.
Al extraer el acceso a datos hacia la capa externa, es posible utilizar objetos especiales que simulan el comportamiento de las fuentes de datos reales [4:42]. Esto permite ejecutar pruebas de forma mucho más rápida y confiable, sin depender de infraestructura externa.
El siguiente paso natural después de entender estas razones es aprender cómo estructurar este acceso mediante el patrón repositorio, que permite organizar de forma clara la comunicación con todas estas fuentes de información. ¿Ya has enfrentado el reto de integrar múltiples fuentes de datos en un mismo proyecto?
