Clean Architecture: equilibrio entre la pureza del diseño y la viabilidad técnica

La adopción de Clean Architecture suele presentarse como una meta aspiracional para obtener sistemas flexibles y mantenibles. Robert C. Martin define este modelo como una forma de organizar las dependencias para que las reglas de negocio permanezcan aisladas de detalles técnicos como bases de datos, frameworks o interfaces de usuario. La implementación rígida de estas capas genera, en ocasiones, un fenómeno que algunos equipos describen como "el infierno de los niveles de abstracción": para una funcionalidad simple, como obtener un perfil de usuario, es necesario atravesar varias interfaces y adaptadores antes de llegar a la lógica real.

Un estudio de la Universidad Nacional Mayor de San Marcos registró que, en proyectos incipientes, una versión simplificada de tres capas mejora la mantenibilidad inicial en 14.23% frente al modelo tradicional de cuatro capas. Los autores atribuyen la diferencia a la menor cantidad de interfaces que un desarrollador nuevo debe recorrer para modificar una funcionalidad.

El núcleo de Clean Architecture es la regla de dependencia: el código fuente solo puede apuntar hacia adentro, hacia las políticas de nivel superior. Nada en un círculo interno conoce elementos declarados en un círculo externo.

La comunicación entre fronteras se resuelve mediante el principio de inversión de dependencia. Un caso de uso que necesita persistir datos no depende de MongoDB directamente, sino de una interfaz definida en la capa de dominio; la infraestructura implementa esa interfaz, no al revés:

// Domain/Repositories/IArticuloRepository.cs
// El caso de uso depende de esta abstracción, no de MongoDB
public interface IArticuloRepository
{
    Task<Articulo> ObtenerPorIdAsync(string id);
    Task GuardarAsync(Articulo articulo);
}

// Application/UseCases/PublicarArticuloUseCase.cs
public class PublicarArticuloUseCase
{
    private readonly IArticuloRepository _repositorio;

    public PublicarArticuloUseCase(IArticuloRepository repositorio)
        => _repositorio = repositorio;

    public async Task EjecutarAsync(string articuloId)
    {
        var articulo = await _repositorio.ObtenerPorIdAsync(articuloId);
        articulo.Publicar();
        await _repositorio.GuardarAsync(articulo);
    }
}

// Infrastructure/Repositories/MongoArticuloRepository.cs
// Detalle técnico: implementa la interfaz, vive en el círculo externo
public class MongoArticuloRepository : IArticuloRepository
{
    private readonly IMongoCollection<Articulo> _coleccion;

    public MongoArticuloRepository(IMongoDatabase db)
        => _coleccion = db.GetCollection<Articulo>("Articulos");

    public Task<Articulo> ObtenerPorIdAsync(string id)
        => _coleccion.Find(a => a.Id == id).FirstOrDefaultAsync();

    public Task GuardarAsync(Articulo articulo)
        => _coleccion.ReplaceOneAsync(a => a.Id == articulo.Id, articulo, new ReplaceOptions { IsUpsert = true });
}

Recomendado Desarrollo de Software

Burnout y síndrome del impostor: la crisis silenciosa que destruye equipos de software

Hace 43 días Leer ahora

Si el proyecto migra de MongoDB a otro motor, PublicarArticuloUseCase no cambia una sola línea: solo cambia la implementación de IArticuloRepository.

La separación de responsabilidades facilita escribir pruebas unitarias sobre la lógica de negocio sin depender de infraestructura ni de interfaz de usuario. En el desarrollo de iOS, el uso de Clean Architecture o MVVM elevó la cobertura de pruebas de un 20% en modelos tradicionales a un rango de 70% a 90%, según reportes de equipos que documentaron la transición.

La independencia tecnológica permite migrar de un motor de base de datos a otro sin alterar la lógica de dominio, y la estructura por capas ayuda a que nuevos integrantes localicen el código relevante una vez superada la curva de aprendizaje inicial. En equipos con varios desarrolladores, la división habilita paralelizar tareas: uno define el contrato de la API en la capa de interfaz mientras otro desarrolla la lógica de dominio.

Existen escenarios donde Clean Architecture resulta excesivo. Para una API CRUD simple con menos de 15 endpoints, añadir ocho capas y cuarenta archivos dificulta el mantenimiento en lugar de simplificarlo. Crear una interfaz para cada estructura, incluso cuando solo existe una implementación real, añade carga cognitiva sin beneficio real de desacoplamiento.

Los frameworks con opiniones fuertes, como Django, Flutter o React, a menudo entran en fricción con la estructura de Clean Architecture: forzar el patrón sobre sus convenciones nativas puede generar hasta un 50% de código repetitivo dedicado únicamente a conectar las piezas.

En experimentos comparativos con SonarQube, la arquitectura de tres capas mejoró la testabilidad en 4.29% respecto al modelo tradicional de cuatro capas en aplicaciones pequeñas. La modularidad registró una mejora leve, lo que indica menor acoplamiento entre componentes. La reusabilidad fue la métrica con mayor ganancia, en 4.27%, en sistemas cohesivos.

Recomendado Arquitectura de Software

Arquitectura Dirigida por Eventos: Patrones y Ejemplos en la Nube

Hace 26 días Leer ahora

En Go, la filosofía de simplicidad del lenguaje puede parecer en tensión con Clean Architecture, pero las interfaces implícitas permiten definir contratos cerca de donde se consumen:

// domain/repository.go
type ArticuloRepository interface {
    ObtenerPorID(id string) (*Articulo, error)
    Guardar(a *Articulo) error
}

// usecase/publicar.go
type PublicarArticuloUseCase struct {
    repo domain.ArticuloRepository
}

func (uc *PublicarArticuloUseCase) Ejecutar(id string) error {
    articulo, err := uc.repo.ObtenerPorID(id)
    if err != nil {
        return err
    }
    articulo.Publicar()
    return uc.repo.Guardar(articulo)
}

// infrastructure/mongo_repository.go
// Implementa la interfaz sin que el paquete usecase lo sepa: Go
// no necesita una palabra clave "implements"
type MongoArticuloRepository struct {
    coleccion *mongo.Collection
}

func (r *MongoArticuloRepository) ObtenerPorID(id string) (*Articulo, error) {
    var a Articulo
    err := r.coleccion.FindOne(context.Background(), bson.M{"_id": id}).Decode(&a)
    return &a, err
}

Un antipatrón frecuente en este ecosistema es usar un modelo único con etiquetas de JSON y de base de datos al mismo tiempo, lo que acopla todas las capas y anula el beneficio del patrón.

En iOS, la transición desde MVC hacia Clean Architecture busca resolver el problema de controladores de miles de líneas que gestionan desde la red hasta el formato de las celdas en una tabla:

// UseCase/PublicarArticuloUseCase.swift
// Puro Swift, sin importar UIKit: se ejecuta en milisegundos
// y se prueba sin instanciar un solo componente de UI
protocol ArticuloRepository {
    func obtener(id: String) async throws -> Articulo
    func guardar(_ articulo: Articulo) async throws
}

final class PublicarArticuloUseCase {
    private let repositorio: ArticuloRepository

    init(repositorio: ArticuloRepository) {
        self.repositorio = repositorio
    }

    func ejecutar(id: String) async throws {
        var articulo = try await repositorio.obtener(id: id)
        articulo.publicar()
        try await repositorio.guardar(articulo)
    }
}

No toda aplicación requiere el despliegue completo de capas concéntricas desde el primer día:

Las abstracciones se justifican cuando existe más de una implementación real o cuando la lógica de dominio es lo bastante rica como para requerir aislamiento; antes de eso, añaden coste sin retorno.

Clean Architecture ofrece un marco robusto para sistemas que deben perdurar años y ser gestionados por equipos grandes, donde la consistencia y el aislamiento de errores pesan más que el tiempo de desarrollo inicial. Su aplicación ciega en prototipos o MVP, sin embargo, retrasa la entrega de valor sin un beneficio proporcional: las cifras de mejora en mantenibilidad y testabilidad que arrojan los estudios citados se obtienen en escenarios de sistemas cohesivos con más de una implementación real, no en un CRUD que va a vivir seis meses.

El criterio más confiable no es seguir el diagrama de capas al pie de la letra, sino escuchar dónde duele el desarrollo: si las pruebas son difíciles de escribir porque dependen de la base de datos, ese es el punto para separar capas; si un cambio simple obliga a tocar cinco archivos por una interfaz que solo tiene una implementación, la arquitectura se volvió más compleja que el problema que resuelve. La decisión, en última instancia, se parece menos a una regla de diseño y más a una inversión que solo se amortiza si la longevidad y la complejidad del sistema la justifican.