Clean Architecture en Frontend: Cómo estructurar tus aplicaciones para sobrevivir a la era de la IA
DominicodeHace unos meses audité una aplicación de un cliente que tenía más de 50 componentes. Cuando abrí el archivo de un simple formulario de checkout, me encontré con 750 líneas de código: llamadas directas a fetch, manipulación de tokens de autenticación, formateo de fechas, cálculo de impuestos y renderizado visual de botones. Todo apretado en el mismo sitio.
El cliente me decía frustrado: "Intentamos usar agentes de IA para añadir un nuevo método de pago y el agente rompe la aplicación entera cada vez".
El problema no era la herramienta de IA. El problema es que los modelos de lenguaje necesitan fronteras claras para no perderse. Cuando mezclas UI, estado y lógica de negocio en una bola de barro, obligas a la IA a interpretar miles de líneas irrelevantes para hacer un cambio trivial.
Clean Architecture en frontend no es un capricho teórico. Es la única forma de construir aplicaciones mantenibles que tanto los humanos como los agentes de IA puedan modificar sin romper producción.
El problema del espagueti en la capa de presentación
Durante años nos enseñaron que organizar una app frontend consistía en crear carpetas como /components, /services y /utils.
Esa estructura por "tipo de archivo" suele degenerar en componentes gigantescos que contienen:
- Lógica de UI (animaciones, estados de modales, hovers).
- Lógica de Negocio (validación de carritos, cálculo de descuentos, reglas de usuario).
- Lógica de Infraestructura (llamadas a la API HTTP, almacenamiento en
localStorage).
Cuando un agente de IA intenta refactorizar o añadir una funcionalidad a un componente así, el resultado son alucinaciones, código duplicado y efectos secundarios inesperados. Como demostramos en nuestro post sobre programación defensiva en TypeScript, la falta de contratos claros es la causa principal de fallos silenciosos.
Las 3 Capas de Clean Architecture en Frontend
Para que una aplicación frontend sea desacoplada y amigable para el desarrollo asistido por IA, debemos dividir el proyecto en tres capas concéntricas con reglas de dependencia estrictas:
┌─────────────────────────────────────────────────────────┐
│ Presentación (React / Angular / Vue Components) │
│ └─► Llaman a Casos de Uso │
│ ┌───────────────────────────────────────────────────┐
│ │ Dominio (Entities, Use Cases, Interfaces Repos) │
│ │ └─► Cero dependencias externas o de UI │
│ └───────────────────────────────────────────────────┘
│ ┌──────────────────────────────────────────────────────┐
│ │ Infraestructura (HTTP Repositories, LocalStorage) │
│ │ └─► Implementan las Interfaces del Dominio │
│ └──────────────────────────────────────────────────────┘
└─────────────────────────────────────────────────────────┘
1. Capa de Dominio (El Corazón de tu App)
Contiene las Entidades y los Casos de Uso pura lógica de TypeScript.
- Regla de oro: No importa qué framework estés usando. La capa de dominio NO debe importar nada de React, Angular, Vue o librerías HTTP.
- Ejemplo:
CalcularDescuentoUseCase,UsuarioEntity,CarritoInterface.
2. Capa de Infraestructura (Conexiones Externas)
Implementa las interfaces definidas por el dominio para interactuar con APIs externas, bases de datos o servicios del navegador.
- Ejemplo:
UserHttpRepositoryque implementaUserRepository, clientes Axios/Fetch, adaptores delocalStorage.
3. Capa de Presentación (Vista e Interacción)
Se limita a pintar los datos y capturar eventos del usuario. Sus componentes invocan los Casos de Uso y reaccionan al estado presentado.
- Ejemplo: Componentes visuales, señales/hooks de estado UI, botones, maquetación.
Por qué esta arquitectura multiplica la velocidad de la IA
Cuando tu aplicación sigue Clean Architecture, trabajar con asistentes como Claude Code o Cursor se vuelve ridículamente eficiente:
- Prompting aislado: Si necesitas cambiar una regla de negocio (ej. "los clientes VIP tienen un 15% de descuento en lugar del 10%"), solo le pides a la IA que modifique el archivo
CalcularDescuentoUseCase.ts. La IA no toca ni un solo archivo de UI. - Generación automática de Tests: Probar un Caso de Uso puro de TypeScript no requiere renderizar componentes ni simular el DOM (jsdom/happy-dom). La IA puede escribir y validar 20 unit tests puramente lógicos en 5 segundos.
- Sustitución de UI sin riesgo: Puedes pedirle a un agente de IA que rediseñe un componente visual entero desde cero, sabiendo que la lógica de negocio subyacente permanecerá intacta.
Como explicamos al analizar el graph engineering, proporcionarle a la IA un mapa claro de dependencias previene que introduzca acoplamientos indeseados.
Y recuerda: aunque Clean Architecture aporta enormes beneficios en apps de tamaño mediano y grande, en nuestra guía sobre cuándo NO usar Spec-Driven Development analizamos los casos de uso donde soluciones más simples resultan más recomendables.
Separar las responsabilidades de tu código no es solo una buena práctica de ingeniería; es la mejor inversión para escalar aplicaciones en la era de los agentes autónomos.
Si quieres aprender a diseñar arquitecturas robustas y escalables desde cero, échale un vistazo a los Cursos de Dominicode. Y si quieres construir proyectos complejos en un entorno colaborativo de alto nivel, te esperamos en Dominicode Labs.
Preguntas frecuentes
¿No añade Clean Architecture demasiada sobrecarga de archivos en proyectos pequeños?
Para proyectos tipo "landing page" o prototipos simples de pocas semanas, Clean Architecture puede resultar excesiva. Sin embargo, para aplicaciones que van a vivir en producción durante años o mantenidas por equipos, el ahorro en mantenimiento compensa con creces la estructura inicial.
¿Dónde encaja la gestión de estado (Redux, NgRx, Zustand, Signals)?
La gestión de estado vive en la capa de Presentación/UI. Los stores o señales consumen los Casos de Uso del Dominio y exponen el estado procesado a los componentes visuales.
¿Cómo interactúa el Dominio con las llamadas a la API sin importar HTTP Client?
El Dominio define una interfaz abstracta (ej. export interface UserRepository { getById(id: string): Promise<User>; }). La Capa de Infraestructura implementa esa interfaz con llamadas HTTP reales mediante inyección de dependencias.
¿Por qué los agentes de IA entienden mejor la Clean Architecture?
Porque los límites de responsabilidad están definidos a nivel de carpetas y contratos. La IA no tiene que adivinar dónde termina la lógica de interfaz y dónde empieza la validación de negocio.
Por Bezael Pérez — Developer senior con más de 15 años de experiencia y fundador de Dominicode.