Repository

Media entre el dominio y el almacenamiento, exponiendo colecciones in-memory ilusorias.

Contexto

Quieres trabajar con tu dominio como si fueran colecciones, sin saber si detrás hay SQL, NoSQL o un API.

Problema

Mezclar lógica de negocio con SQL contamina el dominio.
Cambiar la persistencia obliga a tocar el dominio.

Solución

Una interfaz IXxxRepository con Add, GetById, Find que oculta la persistencia.

#Ejemplo en C#

public interface IOrderRepository
{
    Task<Order?> GetAsync(Guid id);
    Task<IReadOnlyList<Order>> FindByCustomerAsync(Guid customerId);
    void Add(Order order);
    void Remove(Order order);
}

public class EfOrderRepository : IOrderRepository
{
    private readonly AppDbContext _db;
    public EfOrderRepository(AppDbContext db) => _db = db;

    public Task<Order?> GetAsync(Guid id) => _db.Orders.FindAsync(id).AsTask();
    public Task<IReadOnlyList<Order>> FindByCustomerAsync(Guid customerId) =>
        _db.Orders.Where(o => o.CustomerId == customerId).ToListAsync()
            .ContinueWith(t => (IReadOnlyList<Order>)t.Result);
    public void Add(Order o) => _db.Orders.Add(o);
    public void Remove(Order o) => _db.Orders.Remove(o);
}

Cuándo NO aplicarlo

Sobre EF Core ya tienes un repositorio (DbSet<T>). Envolverlo añade ruido salvo que el contrato del dominio sea más estrecho (read models, queries específicas).
Para reads simples → considera CQRS con queries directas.

Tradeoffs

Pro	Contra
Aísla el dominio del ORM	Capa fina que muchas veces solo delega
Tests con repositorios fake	Riesgo de exponer LINQ y filtrar EF al dominio

#extra #ddd #persistence