Clean Architecture promete algo muy atractivo.
Separar responsabilidades.
Reducir dependencias.
Facilitar pruebas.
Permitir cambios sin dolor.
En teoría, suena como el antídoto contra el caos.
Pero hay un problema que empieza a aparecer cuando la aplicas en sistemas reales.
Un problema que no está en los diagramas y que tampoco se esconde detrás de un "skill issue".
Estoy hablando de que en algunos casos Clean, termina introduciendo más complejidad de la que elimina.
La popularidad de Clean Architecture no es casual. Durante años, muchos proyectos quedaron atrapados en código acoplado a frameworks, bases de datos o detalles de infraestructura. Cambiar algo pequeño implicaba tocar múltiples capas. Probar lógica de negocio era difícil. Evolucionar el sistema era arriesgado.
Básicamente eso pasó porque había demasiados monolitos gigantes construidos usando arquitectura en capas.
Clean Architecture surge como una respuesta a ese dolor. Separar el dominio del resto del mundo. Mantener la lógica de negocio independiente. Empujar dependencias hacia afuera. La idea central es poderosa y me encanta: proteger el corazón del sistema.
Y cuando se aplica correctamente, puede ser muy valiosa. Permite aislar el dominio, facilita pruebas y evita que decisiones de infraestructura contaminen la lógica de negocio.
El problema no está en la intención, casi nunca ese es el problema.
El problema aparece cuando la arquitectura deja de servir al dominio y el dominio empieza a servir a la arquitectura.
En muchos equipos he visto como Clean Architecture se convierte en una estructura obligatoria.
Capas fijas.
Interfaces para todo.
Abstracciones anticipadas.
El sistema empieza a llenarse de adaptadores, puertos, DTOs, mappers, servicios intermedios. El flujo de una operación simple atraviesa múltiples capas antes de ejecutar lógica real.
Nada de eso es incorrecto por sí mismo. Pero aparece una pregunta incómoda:
¿Estamos reduciendo complejidad… o solo moviéndola?
Y más importante aún:
¿La arquitectura está protegiendo al dominio… o lo está escondiendo detrás de demasiadas abstracciones?
Imagina un caso sencillo. Una operación que valida un pedido y lo guarda. Conceptualmente, la lógica es directa. Sin embargo, en una implementación estricta de Clean Architecture, esa operación puede implicar pasar por controladores, casos de uso, interfaces de repositorio, implementaciones, mappers y entidades intermedias.
El código se vuelve más estructurado, pero también más difícil de seguir. Para entender qué ocurre, hay que navegar múltiples capas. La intención de la lógica queda fragmentada.
Este fenómeno se vuelve más evidente cuando el dominio no es complejo. Clean Architecture brilla cuando hay reglas de negocio densas, invariantes fuertes o necesidad real de independencia. Pero cuando el dominio es simple, la estructura puede volverse más pesada que el problema.
Empieza a aparecer una complejidad distinta: complejidad cognitiva. No está en el número de líneas de código, sino en el esfuerzo mental necesario para entender el flujo. Cambiar algo pequeño implica recorrer varias capas, identificar contratos, revisar abstracciones.
La arquitectura sigue siendo correcta desde el punto de vista teórico. Pero el costo de comprensión aumenta.
Y ese costo rara vez se menciona.
Al contrario, a veces parece que hay una secta al rededor de Clean, sobre eso solo les puedo decir que no pierdan el norte profesional. Está bien que tengan preferencias pero hay que reconocer las debilidades u oportunidades de mejorar que tienen las cosas.
Clean Architecture no elimina la complejidad.
La redistribuye.
Reduce el acoplamiento técnico, pero puede aumentar el acoplamiento conceptual. La lógica queda dispersa entre capas. La intención del dominio se diluye. El sistema se vuelve más flexible, pero también más difícil de leer.
La paradoja es que la arquitectura diseñada para simplificar la evolución puede terminar dificultando la comprensión. Y en sistemas reales, la comprensión es uno de los factores más importantes para evolucionar con seguridad.
Esto no significa que Clean Architecture sea una mala idea. Significa que no es neutra. Introduce trade-offs. Ganas independencia y testabilidad, pero pagas con mayor complejidad estructural. Ganas separación de responsabilidades, pero pierdes inmediatez en la lectura del código.
La decisión no debería ser aplicar Clean Architecture por defecto, sino preguntarse cuándo el dominio justifica esa estructura. En sistemas con reglas complejas, la inversión tiene sentido. En sistemas simples, puede ser innecesaria.
La arquitectura (estructura) deja de ser un patrón universal y se convierte en una herramienta contextual.
Me interesa saber cómo lo has vivido.
Puedes responder este correo y contármelo.
Además tengo un video donde expongo una solución para trabajar con arquitecturas limpias de forma mucho más fácil de llevar a medida que el sistema va evolucionando.