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

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

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: https://github.com/manuelzapata/clean-architecture-example/blob/main/java/domain-model/src/main/java/org/example/domain/application/interfaces/BookingRepository.java

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•

✅