Comprender cómo se organiza un sistema de software de adentro hacia afuera es fundamental para construir aplicaciones mantenibles y escalables. Clean Architecture propone exactamente eso: cuatro capas concéntricas donde las reglas de negocio más estables ocupan el centro y los detalles técnicos quedan en la periferia. A continuación se explica cada capa y los aspectos más relevantes de esta propuesta arquitectónica.
¿Qué representan las entidades en el centro de Clean Architecture?
La capa más interna se denomina entidades [0:17]. El autor las describe como reglas de negocio que aplican a nivel empresarial (enterprise), es decir, reglas tan generales que podrían ser comunes a múltiples aplicaciones dentro de una misma organización. Cuando se diseña un único sistema, las entidades contienen las reglas más amplias y estables de esa aplicación.
¿Cómo complementan los casos de uso a las entidades?
Rodeando a las entidades se encuentra la capa de casos de uso [0:44]. Aquí residen reglas de negocio más específicas de la aplicación, pero que interactúan directamente con las entidades para orquestar la lógica del sistema. Esta separación permite que:
- Las reglas generales permanezcan aisladas de cambios frecuentes.
- La lógica específica se exprese con claridad en cada caso de uso.
- Ambas capas se complementen sin acoplarse a detalles externos.
¿Qué papel cumplen los adaptadores de interfaz?
La tercera capa corresponde a los adaptadores de interfaz [1:05]. Su función es actuar como puente entre los detalles concretos del sistema y el core de la aplicación —entidades y casos de uso—. Un ejemplo típico es una aplicación MVC en un sistema web: el controlador recibe la petición, la transforma y la entrega al caso de uso correspondiente.
¿Dónde encajan los frameworks y drivers?
La capa más externa se llama frameworks y drivers [1:28]. Aquí están los detalles puntuales:
- Base de datos.
- Servidor web.
- Sistema de archivos.
- Cualquier librería o herramienta concreta.
Todo lo que ocurre en esta capa es convertido por los adaptadores de interfaz para que pueda ser procesado por los casos de uso y las entidades [1:40]. De esta forma, el núcleo del sistema nunca depende de tecnologías específicas.
¿Cuál es el origen de Clean Architecture y qué retos presenta?
Fue propuesta por Robert Martin en 2012 [2:02] a través de un artículo que posteriormente se convirtió en el libro Clean Architecture. Este libro está disponible en inglés y en español y resulta una lectura valiosa para profundizar en fundamentos de arquitectura de software.
Un aspecto importante es que Clean Architecture intenta generalizar ideas presentes en la arquitectura hexagonal, la arquitectura cebolla y otras propuestas [2:30]. Sin embargo, el mayor reto que se le señala es la existencia de vacíos en la implementación [2:42]. El libro no profundiza en varios detalles prácticos, lo que ha llevado a distintos ingenieros y arquitectos a intentar llenar esos huecos con sus propias interpretaciones. Esto dificulta encontrar una explicación unificada cuando se buscan respuestas sobre aspectos que la fuente original no cubre [2:55].
Esta realidad no invalida la propuesta, pero sí exige pensamiento crítico al implementarla. Conocer las cuatro capas —entidades, casos de uso, adaptadores de interfaz, frameworks y drivers— ofrece un marco sólido para razonar sobre la separación de responsabilidades en cualquier proyecto. Si has trabajado con alguna variante de estas arquitecturas, comparte tu experiencia y cómo resolviste esos vacíos de implementación.
