Arquitectura limpia: la regla de dependencia
La arquitectura limpia en un lienzo interactivo: entidades, casos de uso, adaptadores de interfaz y frameworks, y la regla de dependencia que mantiene independiente el núcleo.
La arquitectura limpia organiza el código en capas concéntricas —entidades, casos de uso, adaptadores de interfaz, frameworks— bajo una sola regla: las dependencias apuntan siempre hacia dentro, así que el núcleo nunca depende de una herramienta.
Arquitectura limpia: la regla de dependencia
El lienzo interactivo de FlowJam de esta explicación: cada carril, cada fila y cada flecha de arriba forma parte de un diagrama real de QueryChart que puedes abrir y editar.
Cómo leer este diagrama
- Lee la columna de la izquierda de arriba abajo como las cuatro capas, desde la más interna, «Entidades», hasta la más externa, «Frameworks y drivers».
- Después lee la columna de la derecha de arriba abajo como la regla que las gobierna: dependencias hacia dentro, adaptadores en medio y el núcleo intacto.
- Las flechas fluyen de fuera hacia dentro en espíritu, aunque estén dibujadas de izquierda a derecha: el código de cada capa exterior depende de la capa que tiene dentro.
Las cuatro capas
«Entidades: reglas de negocio de toda la empresa» es el anillo más interno: los objetos y las reglas que existen sin importar cómo se entregue la aplicación, como un cliente, una factura o la regla de que una factura no se puede pagar dos veces. «Casos de uso: reglas específicas de la aplicación» orquesta las entidades para un escenario de la aplicación. «Adaptadores de interfaz: controladores, presentadores» traduce entre los casos de uso y el mundo exterior, y «Frameworks y drivers: interfaz, base de datos, web» es el anillo exterior de las herramientas.
La regla de dependencia
«Las dependencias apuntan hacia dentro, nunca hacia fuera» es la única regla que toda la arquitectura existe para hacer cumplir: las dependencias del código fuente cruzan siempre hacia dentro. «Las capas exteriores hablan por el adaptador, no con el núcleo» es el mecanismo: un caso de uso declara una interfaz para guardar una factura y el adaptador de la base de datos la implementa, así que el caso de uso nunca importa la biblioteca de la base de datos.
La recompensa
«Cambia de framework sin tocar el núcleo» y «El núcleo nunca importa un framework» son la prueba de si la regla se ha respetado: migra de una base de datos o de una interfaz a otra y las entidades y los casos de uso no cambian nada. Esa es toda la propuesta de valor: el código más importante y más caro queda aislado del más sustituible.
Relaciones clave y conclusiones
- Las dependencias apuntan siempre hacia dentro: esa única regla es lo que la arquitectura es.
- El núcleo declara interfaces y los anillos exteriores las implementan: el adaptador es la costura.
- Las entidades y los casos de uso son independientes del framework por construcción.
- La recompensa es la sustituibilidad: cambiar de interfaz, de base de datos o de framework web sin tocar el núcleo.
- La arquitectura limpia va de la dirección de las dependencias, no del número de capas.
Cuándo usar este diagrama
- Enseñar la regla de dependencia a un equipo antes de que estructure un código grande.
- Revisar una arquitectura: un caso de uso que importa una biblioteca de interfaz o de base de datos es una violación de la regla, visible en el lienzo.
- Planificar una reescritura o una migración: el lienzo muestra qué capas tienen que sobrevivir y cuáles se pueden sustituir.
Cómo funciona
Renombra las capas con las de tu stack
Sustituye los nombres genéricos de los anillos por los tuyos reales: tus entidades, tus clases de caso de uso, tus controladores y gateways, y tus frameworks reales de interfaz y de base de datos.
Dibuja las costuras de las interfaces
Añade las interfaces que declara el núcleo y qué adaptador implementa cada una, para que el diagrama documente las costuras que cruza la regla de dependencia.
Marca las violaciones
Añade una etiqueta o una forma distinta a cualquier capa que hoy importe hacia fuera, con una nota sobre la refactorización que lo arreglaría: el lienzo sirve también de auditoría.
Muestra un cambio real
Añade una rama en la que un framework exterior se sustituya por otro y los dos se conecten por el mismo adaptador, terminando en el núcleo sin cambios.
Preguntas frecuentes
¿Qué es la arquitectura limpia?
Es un patrón arquitectónico, popularizado por Robert C. Martin, que organiza el código en capas concéntricas: las entidades en el centro, después los casos de uso, después los adaptadores de interfaz y, en el borde, los frameworks y drivers. Su regla rectora es que las dependencias del código fuente apuntan siempre hacia dentro, así que las reglas de negocio del núcleo nunca dependen de los mecanismos de entrega: la interfaz, la base de datos o el framework web.
¿Qué es la regla de dependencia?
La regla de dependencia dice que las dependencias del código fuente tienen que cruzar siempre hacia dentro: una capa exterior puede depender de una capa interior, nunca al revés. En la práctica, las capas interiores declaran interfaces y las exteriores las implementan, así que el código del núcleo no importa nada de las herramientas del borde. El diagrama la dibuja como su propio grupo porque de ella se deriva cualquier otra propiedad de la arquitectura.
¿En qué se diferencia la arquitectura limpia de una arquitectura por capas?
La arquitectura por capas también separa responsabilidades, pero sus dependencias suelen fluir de arriba abajo: la capa de presentación llama a la capa de servicio, que llama a la capa de datos. La arquitectura limpia invierte eso: el núcleo de negocio está en el centro y todo lo demás depende de él, así que la dirección de la dependencia es el rasgo distintivo. La flecha del diagrama hacia el núcleo es esa diferencia hecha visible.
¿Merece la pena la arquitectura limpia en un proyecto pequeño?
No siempre: la ceremonia cuesta más de lo que devuelve cuando las reglas de negocio son triviales o el equipo es de una sola persona. El patrón se gana el sueldo cuando la lógica de negocio es lo bastante compleja como para tener que sobrevivir a las herramientas, o cuando es probable que la interfaz o la base de datos cambien. Las cajas de recompensa del lienzo enuncian el intercambio con honestidad: la seguridad del núcleo se compra con las capas de adaptadores.
Edita este diagrama en QueryChart (FlowJam)
Abre ese mismo lienzo de arquitectura limpia como tu propio diagrama, renombra las capas con las de tu código y traza tus dependencias.