Clean Architecture

1. La arquitectura de software se centra en minimizar los recursos humanos y maximizar la productividad

El objetivo de la arquitectura de software es minimizar los recursos humanos necesarios para construir y mantener el sistema requerido.

Las decisiones arquitectónicas importan. Una buena arquitectura reduce el esfuerzo necesario para desarrollar, desplegar y mantener sistemas de software. Permite que los equipos trabajen de manera independiente, minimiza el impacto de los cambios y permite que el sistema evolucione con el tiempo.

Aspectos clave de una buena arquitectura:

• Separación de preocupaciones
• Gestión de dependencias
• Abstracción de detalles de implementación
• Flexibilidad para acomodar cambios futuros

Al centrarse en estos aspectos, los arquitectos pueden crear sistemas que sean más fáciles de entender, modificar y extender, lo que en última instancia conduce a un aumento de la productividad y a una reducción de costos a lo largo de la vida útil del sistema.

2. La arquitectura limpia separa las reglas de negocio de los detalles externos

El centro de tu aplicación no es la base de datos. Tampoco lo son uno o más de los frameworks que puedas estar utilizando. El centro de tu aplicación son los casos de uso de tu aplicación.

Las reglas de negocio son el núcleo. La arquitectura limpia organiza el código en círculos concéntricos, con las reglas de negocio en el centro y los detalles de implementación en las capas externas. Esta separación permite que la lógica de negocio central permanezca inalterada por cambios en factores externos como bases de datos, interfaces de usuario o frameworks.

Capas clave en la arquitectura limpia:

• Entidades: Reglas de negocio a nivel empresarial
• Casos de Uso: Reglas de negocio específicas de la aplicación
• Adaptadores de Interfaz: Convierten datos entre casos de uso y agencias externas
• Frameworks y Controladores: Herramientas y tecnologías externas

Al adherirse a esta estructura, los desarrolladores pueden crear sistemas que sean:

• Más flexibles y adaptables al cambio
• Más fáciles de probar y mantener
• Menos dependientes de tecnologías o frameworks específicos

3. Los principios SOLID guían la creación de sistemas flexibles y mantenibles

Los principios SOLID nos dicen cómo organizar nuestras funciones y estructuras de datos en clases, y cómo deben estar interconectadas esas clases.

SOLID mejora la modularidad. Estos cinco principios proporcionan pautas para crear sistemas de software que sean más comprensibles, flexibles y mantenibles. Ayudan a los desarrolladores a diseñar código que sea resistente a los cambios y fácil de extender.

Los principios SOLID son:

• Principio de Responsabilidad Única: Una clase debe tener solo una razón para cambiar
• Principio de Abierto/Cerrado: Las entidades de software deben estar abiertas para extensión pero cerradas para modificación
• Principio de Sustitución de Liskov: Los objetos de una superclase deben ser reemplazables con objetos de sus subclases sin afectar la corrección del programa
• Principio de Segregación de Interfaces: Muchas interfaces específicas de cliente son mejores que una interfaz de propósito general
• Principio de Inversión de Dependencias: Los módulos de alto nivel no deben depender de módulos de bajo nivel; ambos deben depender de abstracciones

Al aplicar estos principios, los desarrolladores pueden crear arquitecturas de software más robustas y escalables que puedan adaptarse a requisitos cambiantes con el tiempo.

4. Los componentes son los bloques de construcción de una arquitectura limpia

Los componentes son las unidades de despliegue. Son las entidades más pequeñas que se pueden desplegar como parte de un sistema.

El diseño modular permite flexibilidad. Los componentes en la arquitectura limpia son partes del sistema que se pueden desarrollar y desplegar de manera independiente. Encapsulan funcionalidades relacionadas y tienen interfaces bien definidas, lo que permite un mantenimiento y modificación más sencillos del sistema.

Características clave de los componentes bien diseñados:

• Alta cohesión: Funcionalidad relacionada agrupada
• Bajo acoplamiento: Mínimas dependencias entre componentes
• Interfaces claras: Métodos de interacción bien definidos
• Desplegabilidad independiente: Se pueden actualizar o reemplazar sin afectar otras partes del sistema

Al organizar los sistemas en componentes, los arquitectos pueden:

• Facilitar el desarrollo paralelo por diferentes equipos
• Permitir pruebas y depuración más fáciles
• Permitir actualizaciones e incrementos en el sistema
• Mejorar la escalabilidad y mantenibilidad general del sistema

5. Los límites definen y protegen la lógica de negocio central

En cada límite arquitectónico, es probable que encontremos el patrón del Objeto Humilde acechando en algún lugar cercano.

Los límites protegen el núcleo. Los límites arquitectónicos en la arquitectura limpia separan diferentes áreas de preocupación, particularmente entre la lógica de negocio y los detalles de implementación. Estos límites ayudan a mantener la independencia de las reglas de negocio centrales frente a cambios externos.

Aspectos clave de los límites arquitectónicos:

• Uso de interfaces para definir interacciones entre capas
• Inversión de dependencias para asegurar que las dependencias apunten hacia adentro
• Objetos de transferencia de datos para pasar información a través de los límites
• Objetos humildes para separar el comportamiento comprobable de los componentes difíciles de probar

Al establecer límites claros, los arquitectos pueden:

• Minimizar el impacto de los cambios en sistemas o tecnologías externas
• Facilitar pruebas más fáciles de la lógica de negocio central
• Permitir el reemplazo de detalles de implementación sin afectar el sistema central
• Mejorar la flexibilidad y adaptabilidad general del sistema

6. La arquitectura limpia facilita el desarrollo guiado por pruebas y la desplegabilidad independiente

Una buena arquitectura hace que el sistema sea fácil de cambiar, en todas las formas en que debe cambiar, dejando opciones abiertas.

La capacidad de prueba y la flexibilidad son clave. La arquitectura limpia promueve prácticas que hacen que los sistemas sean más fáciles de probar y desplegar de manera independiente. Al separar preocupaciones y gestionar dependencias, se vuelve más sencillo escribir pruebas unitarias para la lógica de negocio central y desplegar diferentes componentes del sistema por separado.

Beneficios de la arquitectura limpia para pruebas y despliegue:

• Las reglas de negocio centrales se pueden probar sin dependencias de UI, base de datos o externas
• Diferentes componentes se pueden desplegar de manera independiente, permitiendo actualizaciones más fáciles
• Los cambios en un área del sistema tienen un impacto mínimo en otras
• Se pueden agregar nuevas características con menos riesgo de romper la funcionalidad existente

Estas características conducen a:

• Ciclos de desarrollo más rápidos
• Riesgo reducido en los despliegues
• Mayor fiabilidad del sistema
• Mayor flexibilidad para adoptar nuevas tecnologías o cambiar las existentes

7. Los frameworks y las bases de datos son detalles de implementación, no elementos arquitectónicos

Los frameworks son herramientas para ser utilizadas, no arquitecturas a las que conformarse.

La lógica central debe ser independiente del framework. La arquitectura limpia trata los frameworks y las bases de datos como detalles externos que no deben influir en la lógica de negocio central. Este enfoque permite una mayor flexibilidad para cambiar o actualizar estos elementos externos sin afectar la funcionalidad central del sistema.

Principios clave para manejar frameworks y bases de datos:

• Trátalos como complementos a la lógica de negocio central
• Usa inversión de dependencias para mantener la lógica central independiente
• Crea abstracciones para las operaciones de base de datos
• Retrasa las decisiones sobre frameworks y bases de datos tanto como sea posible

Beneficios de este enfoque:

• Más fácil cambiar o actualizar frameworks y bases de datos
• La lógica de negocio central permanece estable a pesar de los cambios externos
• Reducción del bloqueo de proveedor
• Mejora la capacidad de prueba de los componentes centrales del sistema

8. La web es solo otro mecanismo de entrega en la arquitectura limpia

La web es un mecanismo de entrega, y la arquitectura de tu aplicación debe tratarla como tal.

La lógica de negocio es independiente de la entrega. En la arquitectura limpia, la web se trata como un detalle externo, similar a las bases de datos o frameworks. Esta perspectiva permite que la lógica de negocio central permanezca independiente del mecanismo de entrega específico, ya sea una aplicación web, una aplicación de escritorio o una API.

Consideraciones clave para aplicaciones web en arquitectura limpia:

• Separa el código específico de la web de la lógica de negocio central
• Usa adaptadores de interfaz para convertir entre formatos web y estructuras de datos internas
• Trata los frameworks web como complementos al sistema central
• Diseña casos de uso para ser independientes de preocupaciones específicas de la web

Beneficios de este enfoque:

• Más fácil adaptar el sistema a diferentes mecanismos de entrega
• La lógica de negocio central se puede reutilizar en múltiples plataformas
• Pruebas simplificadas de reglas de negocio sin dependencias web
• Mayor flexibilidad para cambiar o actualizar tecnologías web

9. La arquitectura limpia embebida separa las preocupaciones de hardware de la lógica de negocio

Aunque el software no se desgasta, puede ser destruido desde dentro por dependencias no gestionadas en el hardware.

La independencia del hardware es crucial. La arquitectura limpia embebida aplica los principios de la arquitectura limpia a los sistemas embebidos, separando las preocupaciones específicas del hardware de la lógica de negocio central. Esta separación permite actualizaciones más fáciles de los componentes de hardware y una mejor portabilidad del software.

Elementos clave de la arquitectura limpia embebida:

• Capa de Abstracción de Hardware (HAL) para aislar el código específico del hardware
• Lógica de negocio independiente del dispositivo
• Interfaces claras entre componentes de hardware y software
• Uso de inversión de dependencias para gestionar dependencias de hardware

Beneficios de este enfoque en sistemas embebidos:

• Más fácil portar software a nuevas plataformas de hardware
• Pruebas simplificadas de la lógica central sin dependencias de hardware
• Impacto reducido de los cambios de hardware en el sistema general
• Mejora la mantenibilidad y longevidad del software embebido

10. Los microservicios y las arquitecturas orientadas a servicios pueden beneficiarse de los principios de arquitectura limpia

La arquitectura de un sistema se define por límites que separan elementos de software entre sí, y restringen a aquellos de un lado de conocer a los del otro.

Los principios limpios se aplican a todas las escalas. Aunque la arquitectura limpia se discute a menudo en el contexto de aplicaciones monolíticas, sus principios pueden aplicarse efectivamente a microservicios y arquitecturas orientadas a servicios. Estos principios ayudan a mantener la independencia y capacidad de prueba de servicios individuales mientras se gestiona la complejidad de los sistemas distribuidos.

Aplicando arquitectura limpia a microservicios:

• Trata cada microservicio como un contexto delimitado con su propia arquitectura limpia
• Usa interfaces bien definidas para la comunicación entre servicios
• Aplica inversión de dependencias entre servicios
• Mantén la desplegabilidad independiente de los servicios

Beneficios de la arquitectura limpia en microservicios:

• Mejora la modularidad y escalabilidad del sistema general
• Más fácil de entender y mantener servicios individuales
• Mayor flexibilidad para evolucionar y reemplazar servicios
• Reducción del acoplamiento entre servicios, lo que lleva a sistemas más robustos

Última actualización: July 26, 2024