Hay un momento muy específico en la carrera de cualquier ingeniero senior: abres un repo nuevo, buscas la lógica de negocio de una función que actualiza el estado de un pedido, y terminas saltando por seis carpetas distintas. Entity, use case, gateway, presenter, controller, adapter. Veinte minutos después, encuentras la línea que realmente hace algo: un update en una tabla. El resto era ceremonia. Alguien leyó "Clean Architecture" de Robert Martin, se entusiasmó con los círculos concéntricos, y decidió que un CRUD de configuración de usuario merecía la misma separación que el núcleo transaccional de un banco.
Ese es el problema real: aplicar clean architecture sin preguntarte para qué la estás aplicando.
Qué resuelve clean architecture cuando el problema es real
La idea de fondo de clean architecture no es mala, y vale la pena decirlo sin rodeos: separar las reglas de negocio de los detalles de infraestructura (la base de datos, el framework web, el proveedor de mensajería) es una apuesta que paga cuando esas reglas de negocio van a vivir más tiempo que la tecnología que las rodea hoy.
Piensa en un sistema de facturación que procesa las reglas fiscales de 12 países. Esas reglas cambian por ley, no por moda tecnológica. Si las tienes enterradas en controladores de Express o en procedimientos almacenados acoplados a un ORM específico, cada migración de framework se convierte en una reescritura de negocio disfrazada de upgrade técnico. Ahí es donde separar entidades, casos de uso y adaptadores tiene sentido: no porque el libro lo diga, sino porque tienes una razón concreta para que el dominio no sepa que existe PostgreSQL.
Lo mismo pasa cuando el equipo crece. Con quince ingenieros tocando el mismo servicio, necesitas fronteras claras entre "esto es una regla de negocio que discutimos en el comité de producto" y "esto es un detalle sobre cómo lo persistimos hoy". Sin esa frontera, cualquier cambio de librería HTTP te obliga a tocar la lógica de descuentos porque alguien mezcló las dos cosas en el mismo archivo hace dos años. La arquitectura limpia, en este contexto, es un mecanismo de coordinación entre equipos que no se hablan todos los días, no una cuestión estética.
Hay un tercer escenario en el que clean architecture paga y se menciona menos: cuando el mismo dominio necesita exponerse a través de más de una puerta de entrada. Un motor de pricing que sirve a una API REST, a un worker que procesa eventos de una cola, y a un job batch que corre de noche. Si la lógica de cálculo de precio vive pegada al controller REST, terminas copiándola (mal) en el worker y en el batch, o construyendo dependencias cruzadas rarísimas entre esas tres puntas. Separar el caso de uso del adaptador de entrada no es un capricho: es la única forma de que las tres puertas llamen a la misma regla sin duplicarla.
Cuándo la separación en capas es solo teatro arquitectónico
Ahora el otro lado, que es donde la mayoría de los proyectos LATAM que he visto realmente sufren. Un servicio interno que expone tres endpoints para gestionar tags de un catálogo no necesita entidades de dominio, casos de uso independientes del framework, y una capa de adaptadores para hablarle a una tabla de Postgres que probablemente nunca cambie de motor. Eso es puro teatro.
El síntoma es reconocible al toque: para agregar un campo nuevo a un formulario, tocas el DTO, el mapper del DTO a la entidad, el caso de uso, el mapper de la entidad de vuelta al DTO de respuesta, y el controller. Cinco archivos para lo que, en un CRUD directo, habría sido un cambio en un modelo y en un endpoint. Nadie se benefició de esa indirecta. Ni el negocio, que no tiene reglas complejas que proteger, ni el equipo, que probablemente es una o dos personas que se conocen de memoria el código.
Esto pasa con mucha frecuencia cuando alguien junior con ambición arquitectónica (o alguien senior que quiere dejar su huella) aplica el patrón porque es "la forma correcta de hacer software", sin preguntarse si el contexto lo justifica. Uncle Bob nunca dijo que todo sistema necesita cuatro capas. Dijo que la dependencia debe apuntar al dominio cuando este sea el que necesitas proteger. Si no tienes nada que proteger, estás pagando el costo de la indirecta sin percibir ninguno de los beneficios.
He visto el mismo patrón repetirse en distintas startups de la región: el equipo fundador arranca con un monolito directo, sin capas, y funciona bien durante un año y medio. Después contratan a alguien con background en una consultoría grande, que llega con la mejor intención y reescribe el core en una clean architecture completa antes de que el producto tenga confirmado el product-market fit. Seis meses después el negocio pivotea, como pivotean la mayoría de los productos en etapa temprana, y ahora hay que tirar entidades, casos de uso y adaptadores que protegían reglas de negocio que ya no existen. La arquitectura no falló técnicamente. Falló porque se aplicó antes de saber qué había que proteger.
El costo real que nadie menciona en los talks de conferencia
Cada capa que agregas tiene un costo que se paga a diario, no una sola vez. Onboarding más lento, porque un ingeniero nuevo necesita entender cinco conceptos antes de poder tocar una función. Debugging más largo, porque seguir el flujo de una request implica saltar entre archivos que viven en carpetas distintas. Y un costo silencioso que es el peor de todos: menos gente se anima a proponer cambios, porque tocar algo "bien arquitecturado" da miedo aunque el cambio sea trivial.
Ese último punto es el que más les lastima a los equipos. Cuando la arquitectura se vuelve más importante que el problema que resuelve, la gente deja de cuestionarla. Se convierte en dogma. Y el dogma en ingeniería siempre es una señal de que dejaste de pensar en el contexto y empezaste a copiar una estructura que leíste en otro lado.
Lo opinable acá, y lo digo sin medias tintas: clean architecture funciona en sistemas grandes, con múltiples equipos, con lógica de negocio que sabes que va a sobrevivir al framework de turno. Falla, y falla duro, en servicios chicos, en CRUDs administrativos, en herramientas internas que un equipo de tres personas mantiene y entiende de punta a punta. Aplicarla ahí es cargo cult, no disciplina.
Señales concretas para decidir si te conviene
Hay preguntas que puedes hacerte antes de decidir cuántas capas necesita tu proyecto, y ninguna tiene que ver con qué tan de moda está el patrón.
¿Este sistema va a sobrevivir a un cambio de framework o de base de datos en los próximos años? Si la respuesta es sí, invertir para que el dominio no dependa de esos detalles tiene un retorno real. ¿Hay más de un equipo tocando este código sin coordinarse a diario? Si es así, las fronteras explícitas evitan que un cambio de infraestructura rompa una regla de negocio por accidente. ¿La lógica de negocio es compleja de verdad (cálculos, reglas condicionales, flujos de estados) o es básicamente operaciones CRUD con validaciones simples? Si es lo segundo, cualquier capa adicional es pura fricción.
Y la pregunta que más se salta: ¿alguien en este equipo entiende por qué estamos aplicando este patrón, o lo estamos copiando porque así lo vimos en un repo de ejemplo? Si nadie puede explicar qué problema concreto resuelve cada capa en tu contexto, no tienes clean architecture. Tienes una plantilla que decidiste no cuestionar.
Una forma práctica de resolver esto sin caer en ningún extremo es diseñar para migrar, no para predecir. Empiezas con la estructura más simple que funcione: modelos, validaciones, un handler por endpoint. El día en que una regla de negocio empieza a repetirse en tres lugares distintos, o cuando necesitas exponer esa regla a través de un segundo canal además de HTTP, ese es el momento de extraerla en un caso de uso independiente del framework. No antes. La separación en capas debería ser una respuesta a un dolor real que ya sentiste, no una apuesta sobre un dolor que crees que sentirás en dos años. Refactorizar hacia más estructura cuando la necesitas es barato. Cargar con estructura que nunca necesitaste es una hipoteca que paga todo el equipo, todos los días, durante años.
La arquitectura no es el logro, es la herramienta
Acá está mi posición, sin vueltas: la arquitectura de un sistema es una herramienta que existe para resolver un problema específico de mantenibilidad, no algo que muestras en un talk para demostrar que sabes patrones. Cuando no hay ese problema, la herramienta más elegante es no usarla.
Clean Architecture le dio a la industria un vocabulario útil para hablar de dependencias y de la separación de responsabilidades. Eso es valioso y no hay que tirarlo por la borda. Pero el vocabulario se volvió, en muchos equipos, una excusa para no pensar. Seis capas de indirección en un CRUD son la ausencia de una decisión, disfrazada de mejores prácticas, no rigor técnico.
El ingeniero senior que realmente entiende esto es el que puede mirar un sistema y decir, con la misma convicción, "aquí la separación en capas nos va a salvar en dos años" o "aquí es puro overhead y lo vamos a simplificar", no el que aplica el patrón en todos lados por consistencia. Esa capacidad de discriminar contexto, no la memorización del libro, es lo que separa a alguien que entiende arquitectura de alguien que solo la imita.
