Patrón Repository
Abstrae el acceso a datos detrás de una interfaz para que la lógica de negocio nunca sepa si los datos vienen de una base de datos, caché o API — y las pruebas se convierten en un simple cambio.
Por qué importa
Cuando un servicio importa directamente un driver de base de datos o ejecuta SQL en bruto, la regla de negocio y la fontanería de almacenamiento están fusionadas. No puedes probar la regla sin una base de datos real, no puedes cambiar Postgres por Redis sin reescribir el servicio, y cada detalle de almacenamiento se filtra al dominio. El patrón Repository traza una línea limpia: define una interfaz que describe qué necesita el dominio (encontrar pedidos pendientes, guardar un pedido), y luego proporciona implementaciones separadas para almacenamiento en producción y pruebas en memoria. El dominio nunca vuelve a importar un driver.
Las pruebas se vuelven triviales
Con una interfaz de repositorio en su lugar, una prueba unitaria completa para OrderService no necesita base de datos, ni red, ni docker-compose. Inyecta un InMemoryOrderRepository, siémbralo con datos de prueba y verifica los resultados — la prueba se ejecuta en milisegundos y nunca falla por razones externas. En producción, inyecta PostgresOrderRepository a través de tu contenedor DI. El mismo servicio, cero cambios.
💡Conclusión clave
Repository oculta la fontanería. Tu dominio habla con una interfaz — cambiar Postgres por in-memory, Redis o una API remota es una línea en el cableado DI, no una reescritura de la lógica de negocio.
🔧 Algunos ejercicios pueden tener errores. Si algo parece incorrecto, usa el botón Feedback (abajo a la derecha) para reportarlo — nos ayuda a corregirlo rápido.
Pista: Si tu servicio importa un driver de base de datos o un cliente HTTP, el dominio está filtrándose hacia la infraestructura. Define una interfaz, inyéctala, y observa cómo las pruebas se vuelven triviales.
✗ Tu versión