Definición: Patrón de arquitectura de software de Robert C. Martin que separa la lógica de negocio de frameworks, bases de datos e interfaces de usuario mediante capas concéntricas.
— Fuente: NERVICO, Consultoría de Desarrollo de Producto
Qué es Clean Architecture
Clean Architecture es un patrón de arquitectura de software propuesto por Robert C. Martin (“Uncle Bob”) que organiza el código en capas concéntricas con una regla fundamental: las dependencias siempre apuntan hacia dentro. La capa más interna contiene la lógica de negocio pura, completamente aislada de frameworks, bases de datos y mecanismos de entrega como APIs o interfaces gráficas.
El objetivo es que las decisiones tecnológicas (qué base de datos usar, qué framework web elegir) sean detalles de implementación que se pueden cambiar sin afectar las reglas de negocio.
Cómo funciona
La arquitectura se divide en cuatro capas principales. En el centro están las Entities, que representan las reglas de negocio fundamentales. La siguiente capa contiene los Use Cases, que orquestan el flujo de datos entre entidades. Después vienen los Interface Adapters, que convierten datos entre el formato que usan los casos de uso y el que necesitan los mecanismos externos. La capa exterior son los Frameworks and Drivers: la base de datos, el servidor web, la interfaz de usuario.
La regla de dependencia establece que el código de una capa interna nunca puede conocer ni depender de nada en una capa externa. Esta inversión de dependencias se logra mediante interfaces definidas en las capas internas e implementadas en las externas.
Por qué importa
Clean Architecture permite que los equipos trabajen en paralelo sobre diferentes capas sin conflictos. Facilita los tests unitarios porque la lógica de negocio no depende de infraestructura. Y cuando llega el momento de cambiar de base de datos, migrar a otro framework o exponer una API nueva, el impacto se limita a las capas externas.
Ejemplo práctico
Un sistema de facturación implementa la regla “aplicar 21% de IVA a facturas nacionales” como una Entity. El caso de uso “Crear Factura” orquesta la validación y el cálculo. Un adapter convierte la factura al formato que necesita PostgreSQL para persistirla. Si mañana se migra a MongoDB, solo cambia el adapter. La regla del 21% de IVA permanece intacta.