Implementación del Patrón Repository en Arquitectura de Software

Clase 19 de 24 • Curso de Arquitecturas Limpias para Desarrollo de Software

Resumen

Descubriendo el patrón Repository: Un puente entre el dominio y el acceso a datos

La programación a menudo se enfrenta al desafío de cómo separar el dominio de los elementos técnicos del acceso a datos. La solución más común a este problema es el uso del patrón Repository, que esencialmente actúa como una fachada, ofreciendo una colección de objetos al usuario y ocultando los detalles específicos de la persistencia de datos. Este patrón es fundamental para mantener el código organizado, permitiendo que las operaciones de datos sean independientes de los métodos de acceso y almacenamiento específicos.

¿Qué es el patrón Repository?

El patrón Repository es un diseño utilizado para desacoplar la lógica de negocio de la interacción con la base de datos. Se comporta como una interfaz entre el dominio de la aplicación y la capa de datos, proveyendo al desarrollador un método de acceso a datos abstracto que se puede implementar de diversas maneras.

¿Cómo funciona el patrón Repository?

El patrón se basa en una estructura muy clara donde se definen interfaces en la capa de dominio o aplicación, las cuales describen las operaciones básicas que se pueden hacer con una colección de objetos. La implementación de estas operaciones estará en la capa de infraestructura, oculta detrás de la interfaz y con ello los detalles específicos del acceso a datos.

Agregar un objeto: Añade un nuevo elemento a la colección.
Quitar un objeto: Elimina un elemento existente.
Encontrar un objeto: Ubica y retorna un objeto basado en un identificador o parámetros específicos.

¿Dónde se colocan las interfaces y las implementaciones en el patrón Repository?

La organización de la interfaz y su implementación es crucial en el diseño de software:

Interfaz del repositorio: Debería estar en la capa de aplicación o dominio.
Implementación del repositorio: Va en la capa de infraestructura o capa externa, conteniendo los detalles específicos de la implementación, como la conexión a una base de datos MySQL o la manipulación de archivos.

¿Por qué es importante la inyección de dependencias en este patrón?

La inyección de dependencia es la técnica que permite integrar las interfaces con sus implementaciones concretas, garantizando que las clases de la capa de aplicación solo interactúen con las abstracciones definidas y no con los detalles de la infraestructura.

Ejemplo de código con el patrón Repository

Analizando un caso de uso en una aplicación de reservas de vuelos, se puede encontrar:

FlightRepository interface: Dentro de la capa de aplicación, define las operaciones sin detalles de implementación.
In-Memory Flight Repository: Como implementación de la interfaz, maneja los detalles específicos, como la consulta SQL y la creación de tablas.

Reto para practicar el patrón Repository

Una excelente forma de establecer un entendimiento profundo del patrón Repository es ponerlo en práctica:

Clonar el repositorio proporcionado.
Crear una nueva implementación del repositorio de vuelos.
Probar esa implementación con el servicio ya creado.

El tipo de implementación es a elección del desarrollador, fomentando la creatividad y adaptabilidad.

El estudio y aplicación del patrón Repository es esencial para el progreso de cualquier estudiante de programación que busca una comprensión robusta de cómo gestionar la persistencia de datos. Como experto en estos temas, te animo a explorar este patrón en profundidad, y te aseguro que su dominio traerá claridad y eficiencia a tu trabajo como desarrollador. ¡Adelante, el mundo de la arquitectura de software está esperando por tus habilidades!

Stiven Ramírez Arango

student•

Patrón Repository

¿Cómo separar el dominio del acceso a datos?

Una forma es usando el patrón Repository, el cual ofrece una fachada que da la apariencia de estar usando colecciones y esconde los detalles específicos sobre el funcionamiento de la persistencia.

La interfaz hace parte de la capa de la aplicación, mientras que la implementación hace parte de la capa externa.

Ejemplo:

Se tiene una interfaz denominada ProductRepository, la cual define la firma de los métodos:

add(Product)
findById(int)
remove(Product)

Se tiene una clase que implementa la interfaz ProductRepository y es denominada ProductoRepositoryImpl, la cual tiene la implementación de cada uno de los métodos mencionados con anterioridad:

add(Product)
findById(int)
remove(Product)

De esta forma se podría crear una nueva clase que implemente esa interfaz y pueda realizar operaciones de lectura o escritura de diferentes fuentes de datos, sin tener el dominio atado a una implementación en específico, que es básicamente lo que se busca en un arquitectura limpia.

Luis Sandoval

student•

Hola profe, tengo una consulta, se podría considerar una buena practica, patrón IUnitOfWork con el patró de repositorio, es decir que una interfaz le brinde el acceso a las interfaces de repositorio a la capa de aplicación por medio de una sola interfaz (IUnitOfWork) ? lo he visto en .NET mayoritariamente.

Andres Duque

student•

Una consulta , para realizar el insert en

InMemoryBookingRepository:save

ocupamos un sql statement directamente , es posible utilizar en la capa 'external' un modelo de un ORM para mapear el modelo Booking de la capa de dominio ?

Manuel Zapata

teacher•

Por supuesto! La implementación del repositorio es libre a lo que capa de datos necesite, o a la forma cómo se desee implementar.

Jhon Fredy Martinez Realpe

student•

Hola Manuel,

El Patrón Repository es el mismo DAO?

Julián Esteban Oliveros Forero

student•

Link:

José Antonio De La Paz Fonseca

student•

El dominio en el contexto de arquitectura de software se refiere a la lógica y reglas de negocio que son específicas para la aplicación que estás desarrollando. Es la representación del problema que estás tratando de resolver. En un diseño de arquitectura limpia, es importante que el dominio esté separado de otros aspectos como el acceso a datos o la interfaz de usuario, lo cual se logra mediante patrones como el Repository. Esto permite que el dominio sea más flexible y fácil de mantener.

Jose David Campos

student•

Manuel Zapata

teacher•

Hola Jose David y Luis! Supongo que se refieren a una implementación como esta.

No tengo una opinión sobre si es buena práctica o no ya que no he utilizado Unit of Work en proyectos reales. Inicialmente, pareciera que no es inconveniente.

Carlos Orjuela

student•

Este es uno de los pilares fundamentales de la arquitectura limpia, y entenderlo bien te da control, escalabilidad y desacoplamiento real en tus aplicaciones.

¿Qué es el Patrón Repository?

El patrón Repository actúa como una interfaz entre el dominio y la infraestructura de datos. Su objetivo principal es separar la lógica de negocio (modelo, entidades, casos de uso) del detalle técnico de cómo se acceden o almacenan los datos (BD, APIs, archivos, etc.).

Es como un contrato limpio que dice: “yo quiero guardar, buscar, eliminar… no me importa cómo lo hagas”.

¿Por qué usarlo en arquitectura limpia?

• Desacopla dominio de persistencia: El dominio no sabe si los datos vienen de SQLite, Firebase, REST, etc.
• Facilita testing y mocking: Puedes simular un repositorio en pruebas sin tocar base de datos real.
• Permite cambiar implementación: Si cambias de SQLite a Isar o PostgreSQL, no cambia el dominio.
• Claridad y responsabilidad única: El repositorio solo expone operaciones de persistencia, no lógica.

¿Dónde se ubica en la arquitectura limpia?

[ Presentation / UI ]

↓

[ Application Layer ]

(UseCases llaman repositorios)

↓

[ Domain Layer ]

(Define Entity + IRepositorio)

↓

[ Infrastructure / Data Access ]

(Implementa los repositorios reales)

Ejemplo real en contexto Flutter / Backend

Paso 1 – Definir el contrato en el dominio: Esto vive en el dominio, no depende de nada técnico.

abstract class PedidoRepository {
  Future<Pedido> obtenerPorId(String id);
  Future<void> guardar(Pedido pedido);
  Future<List<Pedido>> listarPorCliente(String clienteId);
}
```Paso 2 – Implementación en infraestructura: Esto ya depende de detalles técnicos (HTTP, JSON, Isar, SQLite...).

```js
class PedidoRepositoryImpl implements PedidoRepository {
  final PedidoApi api; // o BD

  @override
  Future<Pedido> obtenerPorId(String id) async {
    final response = await api.getPedido(id);
    return Pedido.fromJson(response);
  }

  @override
  Future<void> guardar(Pedido pedido) async {
    await api.postPedido(pedido.toJson());
  }

  @override
  Future<List<Pedido>> listarPorCliente(String clienteId) async {
    final lista = await api.listPedidos(clienteId);
    return lista.map(Pedido.fromJson).toList();
  }
}
```Paso 3 – Uso desde un caso de uso: El caso de uso no sabe ni le importa cómo se guardan los datos, solo pide el resultado.

```js
class CrearPedido {
  final PedidoRepository repository;

  CrearPedido(this.repository);

  Future<void> ejecutar(PedidoDTO dto) async {
    final pedido = Pedido.crearDesdeDTO(dto);
    await repository.guardar(pedido);
  }
}
```**Reglas de oro del patrón Repository**

* •	El dominio nunca debe importar infraestructura**:** Mantiene el núcleo limpio y portable.
* •	Define interfaces en el dominio o aplicación: Es el contrato a cumplir.
* •	Implementa los detalles en la infraestructura: Se puede cambiar sin afectar lógica de negocio.
* •	Se puede cambiar sin afectar lógica de negocio: El repo trabaja con el lenguaje del dominio.

Carlos Orjuela

student•

Tanto escribir para que la plataforma acomode los estilos del texto entre código y descripciones :(

Cholca Campues Byron Giovanny

student•

Saludos, porque la implementación(lógica del negocio) debe estar en la capa externa en el repository

Víctor Rolack

student•

Porque no es lógica del negocio como tal, sino que es la implementación de la herramienta que estás usando para ejecutar lógica que es del negocio. Por ejemplo, un caso de lógica de negocio es agregar un producto, pero el cómo hacerlo es indiferente del negocio porque podrías hacerlo de múltiples maneras con múltiples herramientas, pero el objetivo es el mismo, que el método agregue el producto.

Entonces tienes en tu interface qué quieres y en la implementación cómo se hará. La interface es una y queda lo más inmutable posible y la implementación pueden ser muchas con distintas formas de agregar el producto.

ANDRES ALFONSO MIRA MEJIA

student•

✅

abstract class PedidoRepository {
  Future<Pedido> obtenerPorId(String id);
  Future<void> guardar(Pedido pedido);
  Future<List<Pedido>> listarPorCliente(String clienteId);
}
```Paso 2 – Implementación en infraestructura: Esto ya depende de detalles técnicos (HTTP, JSON, Isar, SQLite...).

```js
class PedidoRepositoryImpl implements PedidoRepository {
  final PedidoApi api; // o BD

  @override
  Future<Pedido> obtenerPorId(String id) async {
    final response = await api.getPedido(id);
    return Pedido.fromJson(response);
  }

  @override
  Future<void> guardar(Pedido pedido) async {
    await api.postPedido(pedido.toJson());
  }

  @override
  Future<List<Pedido>> listarPorCliente(String clienteId) async {
    final lista = await api.listPedidos(clienteId);
    return lista.map(Pedido.fromJson).toList();
  }
}
```Paso 3 – Uso desde un caso de uso: El caso de uso no sabe ni le importa cómo se guardan los datos, solo pide el resultado.

```js
class CrearPedido {
  final PedidoRepository repository;

  CrearPedido(this.repository);

  Future<void> ejecutar(PedidoDTO dto) async {
    final pedido = Pedido.crearDesdeDTO(dto);
    await repository.guardar(pedido);
  }
}
```**Reglas de oro del patrón Repository**

* •	El dominio nunca debe importar infraestructura**:** Mantiene el núcleo limpio y portable.
* •	Define interfaces en el dominio o aplicación: Es el contrato a cumplir.
* •	Implementa los detalles en la infraestructura: Se puede cambiar sin afectar lógica de negocio.
* •	Se puede cambiar sin afectar lógica de negocio: El repo trabaja con el lenguaje del dominio.

Implementación del Patrón Repository en Arquitectura de Software

Introducción al curso

Arquitectura Limpia: Enfoque y Aplicación en Java y C#

Conceptos detrás de las Arquitecturas Limpias

Arquitectura de Software: Tres Capas y MVC

Características y Beneficios de la Arquitectura Limpia

Cuándo aplicar o ignorar arquitecturas limpias en desarrollo software

Principios SOLID: Aplicación Práctica en Arquitecturas Limpias

Arquitecturas de referencia

Arquitectura Hexagonal: Puertos y Adaptadores en Desarrollo de Software

Arquitectura Onion: Diseño y Aplicación en Desarrollo de Software

Desglose de Capas en Clean Architecture

Implementación de Arquitectura Limpia en Empresas Reales

Conclusiones sobre Arquitectura de Software Adaptativa

Dominio de una arquitectura

Errores Comunes al Manejar la Lógica de Dominio en Sistemas de Información

Script de Transacción en Arquitectura de Software

Inyección de Dependencias e Inversión de Control en Java

Modelos de Dominio en Programación Orientada a Objetos

Capa de Servicios y Fachada en la Arquitectura de Software

Casos de Uso en Clean Architecture con C#

Implementación de CQRS en Arquitecturas Limpias con C#

Capa externa

Acceso a Datos en Arquitectura Limpia: Fuentes y Pruebas Efectivas

Implementación del Patrón Repository en Arquitectura de Software

Implementación de APIs y Web con Spring Boot en Arquitectura Limpia

Implementación de Integraciones con el Patrón Adapter en Arquitectura Limpia

Pruebas Unitarias en Arquitecturas Limpias con Java y Spring Boot

Pruebas de Integración con Dobles de Prueba en Aplicaciones

Cierre

Desafíos y Recomendaciones en Arquitectura Limpia