Integrar una aplicación web o un REST API dentro de una arquitectura limpia es más sencillo de lo que parece, siempre que recuerdes una regla básica: ambos pertenecen a la capa externa. Esta guía te muestra cómo conectar Spring Boot con tu dominio sin contaminar la lógica de negocio, ideal si trabajas con Java o cualquier framework web moderno.

¿Por qué la web y los APIs viven en la capa externa?

La interfaz que elijas (web, móvil, desktop o un API REST) es un detalle de entrega, no el corazón de tu sistema. Por eso, en Clean Architecture todas estas piezas se ubican en la capa más externa, lejos del dominio.

Esto tiene una consecuencia práctica muy poderosa: tu lógica de negocio sigue siendo agnóstica a la tecnología. Hoy expones tu sistema con Spring Boot, mañana podrías hacerlo con ASP.NET o con una app de escritorio, y el dominio no se entera.

¿Qué es la capa externa en Clean Architecture? Es la capa que contiene los detalles de tecnología: controladores web, frameworks, bases de datos y APIs. Todo lo que pueda cambiar sin romper las reglas de negocio.

¿Cómo se ve un controlador con Spring Boot dentro de Clean Architecture?

En el ejemplo en Java se agregó un paquete Rest dentro de la capa externa. Allí viven los controladores, como un HelloController, junto con la clase que levanta el servicio.

El controlador es deliberadamente simple. Define sus dependencias y las recibe vía inyección de dependencias, una funcionalidad que Spring Boot ofrece de forma automática. Una vez declaradas, esas dependencias se pueden usar en cualquier método del controlador sin instanciar nada manualmente.

Y aquí aparece algo interesante: este controlador sí tiene una implementación específica de Spring Boot. ¿Está mal? No, porque vive en la capa externa, justo donde los detalles tecnológicos son bienvenidos.

¿Cómo funciona la inyección de dependencias dinámica?

Para evitar configurar manualmente cada nuevo servicio, interfaz o repositorio, se implementó un código adicional que aprovecha funcionalidades de Spring Boot para descubrir dependencias en tiempo de ejecución e inyectarlas automáticamente.

Esto significa que cuando creas un nuevo caso de uso o repositorio, no necesitas tocar archivos de configuración. El sistema los encuentra solo. El código completo está disponible en el área de recursos.

La mayoría de los frameworks web ofrecen este mecanismo. ASP.NET, por ejemplo, trae inyección de dependencias prácticamente de base.

¿Qué errores debo evitar al construir REST APIs con arquitectura limpia?

Hay dos situaciones que se filtran constantemente en proyectos reales y que conviene cortar de raíz.

¿Por qué no debo poner lógica de negocio en la vista?

La tentación clásica es tomar un atajo: pongo la validación o la regla aquí en la vista, y después la muevo al dominio. Spoiler: ese después casi nunca llega. Los cambios temporales se vuelven permanentes y la lógica termina dispersa por toda la aplicación.

Si detectas lógica de negocio en una vista, tómate el tiempo de ubicarla bien:

• Decide a qué parte del dominio pertenece.
• Evalúa si necesitas modificar entidades.
• Revisa si hay que ajustar alguna interfaz.
• Implementa la solución organizada desde el inicio.

¿Dónde debe vivir la lógica de negocio? Siempre en el dominio, nunca en la vista ni en el controlador. La capa externa solo orquesta y traduce.

¿Cómo deben comportarse los controladores?

El rol de un controlador es muy específico: recibir una solicitud desde la vista y decidir a qué parte del dominio invocar para resolverla. Nada más.

Un controlador se contamina cuando empieza a:

• Hacer validaciones de negocio muy específicas.
• Encadenar múltiples llamadas con lógica entre ellas.
• Tomar decisiones que deberían vivir en una entidad o caso de uso.

Lo ideal es que tus controladores funcionen como pasarelas. Llega información, haces validaciones generales propias de la vista (formato, campos requeridos), llamas al dominio, esperas un resultado y notificas de vuelta.

¿Qué validaciones puede hacer un controlador? Solo las que dependen del transporte: que el JSON tenga los campos esperados, que los tipos sean correctos, que el request esté bien formado. Las reglas de negocio no.

Mientras mantengas esa disciplina, integrar Spring Boot, ASP.NET o cualquier framework web con tu arquitectura limpia se vuelve un ejercicio mecánico. ¿Has tenido que rescatar lógica de negocio atrapada en un controlador? Cuéntame cómo lo resolviste.