Repository Pattern: deja de acoplar tu dominio a la base de datos

El Repository Pattern es la herramienta que te permite diseñar el dominio primero y postergar la decisión de infraestructura. Implementación real en Code Finances con TypeORM.

Volviendo con la serie de Code Finances, hoy tocamos una de las decisiones más importantes — y muchas veces mal tomadas — en desarrollo de software: elegir primero la base de datos.

Sí, esa típica pregunta al empezar un proyecto:

"¿Usamos MongoDB o PostgreSQL?"

❌ Error.

💡 Cambiemos la pregunta

¿Y si diseñamos primero el dominio? ¿Y si pudiéramos acceder a datos sin depender de una tecnología concreta?

Aquí es donde entra el Repository Pattern.

🔍 ¿Qué es el Repository Pattern?

Es un patrón que nos permite encapsular la lógica de persistencia y desacoplar el dominio de la infraestructura. Tu dominio no sabe si usas SQL, NoSQL o cualquier otra cosa.

📐 Cumpliendo SOLID de forma natural

• ✅ SRP — cada clase tiene una única responsabilidad
• 🔓 OCP — puedes extender sin modificar
• 🔌 DIP — dependes de interfaces, no de implementaciones

🛠️ Implementación en Code Finances

📦 Dominio — la abstracción

interface LiquidityCategoryRepository {
  save(category: LiquidityCategory): Promise<void>
}

⚙️ Aplicación — el caso de uso depende de la interfaz

class LiquidityCategoryCreator {
  constructor(private repository: LiquidityCategoryRepository) {}

  async execute(category: LiquidityCategory) {
    await this.repository.save(category)
  }
}

🏗️ Infraestructura — la implementación concreta

class TypeOrmLiquidityCategoryRepository implements LiquidityCategoryRepository {
  async save(category: LiquidityCategory): Promise<void> {
    // lógica con TypeORM
  }
}

flowchart TB
    subgraph Aplicacion[Aplicación]
        UC["LiquidityCategoryCreator<br/>caso de uso"]
    end

    subgraph Dominio
        I["LiquidityCategoryRepository<br/>interfaz"]
    end

    UC -->|depende de| I

    subgraph Infraestructura
        direction TB
        IMPL["TypeOrmLiquidityCategory<br/>Repository"]
        DB[("PostgreSQL<br/>TypeORM")]
        IMPL --> DB
    end

    subgraph Tests
        MOCK["InMemoryRepository<br/>mock"]
    end

    I -.->|implementa| IMPL
    I -.->|implementa| MOCK

    style Dominio fill:#1e1b4b,stroke:#818cf8,color:#e0e7ff
    style Aplicacion fill:#0f172a,stroke:#818cf8,color:#e0e7ff
    style Infraestructura fill:#0f172a,stroke:#818cf8,color:#e0e7ff
    style Tests fill:#1e3a1e,stroke:#4ade80,color:#dcfce7

🔄 ¿Qué conseguimos?

• 🔌 Desacoplamiento total de la base de datos
• 🧪 Tests unitarios simples — usando mocks de la interfaz
• 🔄 Flexibilidad para cambiar de tecnología sin tocar el dominio
• 🚀 Desarrollo centrado en el dominio

⚠️ El error común

💬 Conclusión

El Repository Pattern no es solo un patrón más. Es una herramienta que te permite diseñar mejor, cambiar sin romper y mantener tu dominio limpio.

Porque al final: la base de datos es un detalle. El dominio es lo importante.

Publicado originalmente en LinkedIn.