Hola devs, admitámoslo: a los desarrolladores backend nos encanta la sobreingeniería jaja. Nos da una falsa sensación de seguridad. Vemos un repositorio en GitHub con 150 estrellas que promete la arquitectura limpia definitiva para .NET y, sin pensarlo, lo usamos como plantilla para nuestro próximo proyecto.

Tres semanas después, para añadir un simple campo Status a una entidad de la base de datos, tienes que tocar:

• La entidad del Core.
• El DTO de la capa de Application.
• El validador de FluentValidation.
• El perfil de AutoMapper.
• El Command de MediatR.
• La migración en Infrastructure.
• El Request/Response en la API (Presentation).

Felicidades capo, acabas de crear una burocracia de código para un sistema que probablemente solo procesa tres peticiones por minuto. Y cual es el resultado? Tu velocidad de entrega ha caído en picado y tu equipo odia abrir el IDE...

El mito del desacoplamiento absoluto

El argumento principal para meter cuatro capas, interfaces para todo e inyección de dependencias extrema es: "Por si mañana cambiamos de SQL Server a MongoDB".

Spoiler: No lo vas a hacer. En los últimos 10 años, ¿cuántas veces has cambiado de base de datos en un entorno real de producción? Probablemente ninguna. Y si llega a pasar, el cambio de paradigma de relacional a no-relacional va a romper tu lógica de negocio de todas formas, por muchas interfaces IRepository que hayas metido.

Te aporto mi experiencia: En 14 años trabajando en proyectos empresariales todavía no he participado en una migración completa de SQL Server a MongoDB. Así de claro te lo pongo, por supuesto, esto no es algo concluyente, pero sí te da una pista.

El verdadero acoplamiento del que debes huir no es el de la base de datos; es el acoplamiento entre tus propios casos de uso.

Una alternativa real: Vertical Slices (Rebanadas Verticales)

En lugar de organizar tu código por "capas de cebolla" (técnicas), organízalo por lo que el negocio realmente hace (características). A esto en mis clases, lo suelo llamar Split by Feature.

Si estás usando .NET 10, las Minimal APIs combinadas con un enfoque de Vertical Slices te permiten meter todo lo que un caso de uso necesita dentro de una sola carpeta, o incluso en un solo archivo si es lo suficientemente simple.

Mira este ejemplo de cómo se ve un endpoint práctico de creación de producto sin capas intermedias absurdas:

// Features/Products/CreateProduct.cs

public record CreateProductCommand(string Name, decimal Price);

public static class CreateProductEndpoint
{
    public static void MapCreateProduct(this IEndpointRouteBuilder app)
    {
        app.MapPost("/products", async (CreateProductCommand command, AppDbContext db) =>
        {
            // 1. Validar (Directo, sin tres capas de abstracción)
            if (string.IsNullOrEmpty(command.Name)) 
                return Results.BadRequest("El nombre es obligatorio.");

            // 2. Mapear y Guardar
            var product = new Product { Name = command.Name, Price = command.Price };
            db.Products.Add(product);
            await db.SaveChangesAsync();

            return Results.Created($"/products/{product.Id}", product);
        });
    }
}

¿Cuándo sí tiene sentido Clean Architecture?

No me malinterpretes. La arquitectura limpia no es el demonio, el problema es su uso dogmático.

Aplicar toda su "burocracia" tiene todo el sentido del mundo si:

• Tienes un dominio hipercomplejo con reglas de negocio cambiantes que necesitan aislamiento total de la infraestructura.
• Tienes docenas de desarrolladores tocando el mismo módulo y necesitas límites ultraestrictos para que no se pisen.

Si tu aplicación es un backend que principalmente hace validaciones simples, consultas y escrituras en base de datos, empieza con una arquitectura simple basada en características (Feature-driven). Si el negocio crece y el dolor de la complejidad te lo pide, entonces (y solo entonces) refactoriza hacia capas más abstractas.

Para ser sinceros, la ingeniería de software en gran medida consiste en gestionar trade-offs no en seguir modas de GitHub.

Así que ya lo sabes dev, menos burocracia de carpetas, más código que aporta valor.

Ya sabes, si te ha encantado este artículo compártelo con todo tu equipo de ingeniería.

Créditos de imagen de portada: Foto de Eduardo Cabrera en Unsplash