Puntos clave
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:
FAQ
What's Clean Architecture about?
- Focus on Software Structure: Clean Architecture by Robert C. Martin emphasizes creating systems that are easy to develop, maintain, and deploy through effective software architecture.
- Timeless Principles: It outlines principles like SOLID, applicable across various programming paradigms, to guide developers in writing clean, maintainable code.
- Separation of Concerns: The book advocates for separating business rules from technical details, enhancing flexibility and adaptability in software design.
Why should I read Clean Architecture?
- Improve Software Design Skills: The book enhances understanding of software architecture, providing practical advice for real-world projects.
- Timeless Knowledge: Its principles are not tied to specific technologies, ensuring relevance throughout your career.
- Real-World Examples: Martin shares insights from his extensive experience, offering relatable examples and case studies to simplify complex concepts.
What are the key takeaways of Clean Architecture?
- Architecture is a Shape: Software architecture is defined by component division and communication, facilitating development and maintenance.
- Decouple Business Rules: Emphasizes separating business rules from technical details for easier changes and adaptations.
- Leave Options Open: Good architecture defers technical decisions, allowing flexibility to adapt to changing requirements.
What are the SOLID principles mentioned in Clean Architecture?
- Single Responsibility Principle (SRP): A class should have one reason to change, reducing complexity and easing maintenance.
- Open-Closed Principle (OCP): Software entities should be open for extension but closed for modification, minimizing bug risks.
- Liskov Substitution Principle (LSP): Subtypes must be substitutable for their base types without altering program correctness.
What is the Dependency Inversion Principle (DIP) in Clean Architecture?
- High-Level Modules: DIP states high-level modules should not depend on low-level modules; both should depend on abstractions.
- Abstractions Over Details: Depending on abstractions rather than concrete implementations makes systems easier to modify and extend.
- Use of Interfaces: Encourages using interfaces to define contracts between components, enhancing testing and maintenance.
How does Clean Architecture define good software architecture?
- Support for Use Cases: Good architecture must support intended use cases, making them clear and visible within the structure.
- Minimize Human Resources: It should minimize resources required for development, deployment, and maintenance through careful design.
- Leave Options Open: A well-designed architecture keeps options open for future changes, crucial for long-term success.
What is the significance of boundaries in Clean Architecture?
- Separation of Concerns: Boundaries separate system components, ensuring changes in one area don't adversely affect others.
- Control Over Dependencies: Managing dependencies across boundaries prevents disruptions, leading to a stable system.
- Facilitate Independent Development: Boundaries allow teams to work independently, enhancing productivity and reducing conflicts.
What is the "Screaming Architecture" concept in Clean Architecture?
- Architecture Reflects Intent: "Screaming Architecture" means the system's architecture should clearly communicate its purpose and functionality.
- Use Case Driven: Good architecture is driven by use cases, maintaining clarity and purpose throughout development.
- Avoid Framework Dependency: Architecture should be centered around business needs, not dictated by frameworks or tools.
How does Clean Architecture address testing?
- Testable Architectures: Emphasizes architectures that allow unit testing of business rules without external systems running.
- Humble Object Pattern: Separates hard-to-test code from testable code, focusing on logic without UI or framework complexities.
- Testing API: Suggests creating a testing API to bypass security constraints, enhancing the ability to test various scenarios.
How does Clean Architecture differentiate between the web and the architecture of a system?
- Web as a Delivery Mechanism: The web is viewed as a delivery mechanism, not a defining aspect of system architecture.
- Decoupling Delivery from Logic: Treating the web as a detail allows designing systems agnostic to delivery methods.
- Focus on Business Logic: Prioritizes business logic and use cases over web delivery specifics, ensuring core functionality remains intact.
What are the risks of using frameworks according to Clean Architecture?
- Tight Coupling: Frameworks can lead to tight coupling, making technology switches difficult.
- Overhead and Complexity: Heavy reliance on frameworks can introduce unnecessary complexity and hinder performance.
- Loss of Control: Over-reliance on frameworks can lead to a rigid system, making changes and adaptations challenging.
What are the best quotes from Clean Architecture and what do they mean?
- "Your architecture should tell readers about the system, not about the frameworks you used in your system.": Emphasizes architecture reflecting business domain and use cases, not technologies.
- "Frameworks are tools, not ways of life.": Reminds developers to maintain control over architecture, not be overly reliant on frameworks.
- "A good architecture makes it unnecessary to decide on Rails, or Spring, or Hibernate, or Tomcat, or MySQL, until much later in the project.": Highlights deferring technology decisions until architecture is established, promoting flexibility.
Reseñas
Arquitectura Limpia: Una Guía del Artesano para la Estructura y el Diseño de Software recibe opiniones mixtas. Muchos elogian su enfoque en los principios SOLID y el desacoplamiento, mientras que otros lo encuentran repetitivo y carente de ejemplos prácticos. Algunos lectores aprecian el contexto histórico y las anécdotas, mientras que otros sienten que distraen del contenido principal. En general, el libro se considera útil para comprender conceptos arquitectónicos de alto nivel, pero las opiniones varían sobre su utilidad para principiantes frente a desarrolladores experimentados. Varios críticos señalan que el contenido del libro podría haberse transmitido de manera más concisa.
