El patrón repository resuelve una pregunta clave en arquitectura de software: cómo separar el dominio del acceso a datos sin acoplar tu aplicación a una base de datos específica. Si trabajas con arquitecturas limpias y quieres que tu código sea mantenible, escalable y testeable, este patrón es una de las herramientas más usadas para lograrlo.

¿Qué es el patrón repository y para qué sirve?

La idea central es crear una fachada que simule una colección de objetos. Cuando usas un repositorio, sientes que estás trabajando con un conjunto de objetos en memoria: agregas, eliminas, buscas por identificador. Pero por debajo, los detalles de persistencia quedan completamente ocultos [2:00].

¿Qué es el patrón repository? Es una fachada que expone operaciones tipo colección (agregar, eliminar, buscar) y oculta cómo se guardan o consultan los datos: SQL, NoSQL, archivos o memoria.

La clave está en que quien consume el repositorio no debería enterarse de si por dentro se ejecuta una consulta SQL, si hay una librería específica para una base no relacional o si los datos viven en memoria. Ese ocultamiento es lo que da flexibilidad a tu arquitectura [2:30].

¿Cómo se estructura un repositorio en código?

Normalmente vas a tener dos piezas: una interfaz y una implementación. La interfaz declara los métodos tipo colección, y la implementación se encarga de los detalles técnicos.

Un ejemplo típico en una interfaz incluye:

• Un método para agregar un objeto.
• Un método para encontrar a partir de un identificador.
• Un método para eliminar.

Luego tienes la implementación, que suele nombrarse con sufijo Impl (de implementation). Puedes tener una ProductRepositoryImpl que se conecte con MySQL, otra que lea archivos JSON o XML, y otra que manipule datos en memoria. Todas implementan la misma interfaz [3:30].

¿Dónde van la interfaz y la implementación?

Esta es la duda más frecuente y donde muchos se enredan. La regla es clara:

• La interfaz vive en la capa de aplicación.
• La implementación vive en la capa externa, junto con los detalles de infraestructura.
• La aplicación solo conoce la interfaz, nunca las clases específicas.

Para que la aplicación reciba la implementación correcta sin conocerla, usas inyección de dependencias. Así puedes cambiar de MySQL a un archivo JSON sin tocar la lógica de dominio [4:50].

¿Cómo se ve el patrón repository en un ejemplo Java?

Retomando el ejemplo de una aplicación de reserva de vuelos en Java, encontramos una capa de dominio y una capa de aplicación. Dentro de la capa de aplicación hay una carpeta de interfaces donde vive FlightRepository, y en la capa externa están las implementaciones puntuales como InMemoryFlightRepository [6:00].

Fíjate en algo importante: el nombre de la implementación ya revela detalles, como que usa memoria. Eso está bien, porque vive en la capa externa donde esos detalles son legítimos.

¿Por qué la interfaz va en la capa de aplicación? Porque la aplicación define qué necesita (operaciones de dominio), no cómo se hace. La capa externa decide el cómo: SQL, JSON, memoria, etc.

¿Qué contiene la interfaz vs la implementación?

La interfaz FlightRepository solo define operaciones y referencia entidades del dominio, como la entidad Vuelo y el objeto de valor Ruta. No hay nada de persistencia ahí [7:10].

La implementación, en cambio, sí tiene los detalles puntuales:

• Usa una base de datos H2, que es una base en memoria.
• Ejecuta sentencias para crear la tabla si no existe.
• Contiene SQL puro y duro dentro de los métodos de guardar y consultar.
• Utiliza objetos específicos de la API de persistencia.

Esa separación tan clara entre interfaz e implementación te abre la puerta a sustituir el repositorio en memoria por otro que use una base de datos relacional, sin que el servicio de aplicación se entere [8:30].

¿Cuál es el error más común al implementar repository?

El punto donde más fallan los desarrolladores al adoptar arquitecturas limpias es no apropiarse de la interfaz. El servicio en la capa de aplicación siempre debe conocer interfaces, nunca detalles concretos.

Cuando la interfaz no está bien definida, terminas filtrando dependencias hacia la infraestructura. De repente tu servicio de aplicación importa clases de MySQL o de un ORM específico, y la separación se rompe. La disciplina de respetar la interfaz es lo que sostiene la arquitectura [9:20].

Reto: crea tu propia implementación de repositorio

Para afianzar el concepto, te propongo un ejercicio práctico. Clona el repositorio que encuentras en el área de recursos y crea una nueva implementación de FlightRepository. Ya existe una versión en memoria; tu tarea es construir otra.

Las opciones son tuyas:

• Una implementación basada en archivos (JSON, XML, CSV).
• Una con otro motor de base de datos distinto a H2.
• Una conectada a un servicio de terceros donde puedas guardar y consultar información.

Verifica que tu nueva implementación funcione con el servicio existente sin tocar la capa de aplicación. Ese es el indicador de que el patrón está bien aplicado. Cuéntame en los comentarios cómo te fue y qué decisión tomaste para tu implementación.