Acerca de Clean Architecture

Clean Architecture

Por: Jorge Rebollo

Arquitectura de software

Estructura de un Sistema compuesta de elementos* con propiedades visibles de forma externa y las relaciones que existen entre ellos.

Software Engeenering Institute, SEI.

*definición abstracta: objetos, hilos, clases, componentes…

NO es Arquitectura de software

• Agrupación jerárquica de folders
• Patrones de UI: MVC, MVP, MVVM no implican una arquitectura
• Estructura de un framework

Introducción a Clean Architecture de Uncle Bob (Robert C. Martin)

¿Origen y razón de su existencia?

Resolver problemas de software

¿Qué tipo de problemas?

Problemas de…

• Acomplamiento (funcionalidad de vista, lógica de negocio y de datos).
• Código repetido en muchas partes de la aplicación.
• Hacks por todas partes para solucionar temporalmente problemas específicos.
• Exceso de arquitectura sólo basada en herencia. El mantenimiento es difícil cuando se extienden en profundidad los niveles de herencia.
• Exceso de dependencias externas (librerías) y su consecuencia.
• Y otros tantos con sus respectivas consecuencias…

¿Qué propone Clean Architecture para terminar con estos problemas?

Separación de intereses o principios

(Separation concerns)

Características del Clean Architecture

• Independiente de Framework (iOS, Android, web, etc.)
• La arquitectura no depende de la existencia de ninguna librería cuyas características aten a sus requisitos. Esto permite usar los frameworks como si fueran herramientas, en lugar de someter el sistema a las restricciones impuestas.
• Independiente de UI
• La interfaz gráfica de usuario puede cambiar fácilmente sin cambiar el resto del sistema. Una UI web puede reemplazarse con una interfaz de consola, sin tener que cambiar la lógica de negocio.
• Independiente de base de datos (MongoDB, Realm, etc,)
• Las reglas del negocio no están ligadas a la base de datos. Puede cambiarse el origen de una base de datos por cualquier otra.
• Independiente de factores externos.
• Las reglas de negocio (lógica de negocio) no tienen constancia de nada que provenga del exterior.
• Mejora en la calidad del código.
• Desacoplamiento de código .
• Reutilización de código.
• Testeable.
• Arquitectura sólida aplicable a proyectos de cualquier dimensión.
• Costo / Beneficio: Implementación sencilla vs. ahorro de problemas sustanciales.
• Fácil mantenimiento.
• Flexibilidad.

Lineamientos Clean Architecture

• La arquitectura se centra en lo que hace la aplicación, no en el framework o en las librerías que usa.
• El dominio o modelo de negocio (casos de uso y entidades) deben ser el núcleo de la aplicación.
• Bases de datos, servicios web, framework, librerías, UI, etc. no son relevantes para el modelo de negocio

Diagrama Clean Architecture[pic 1]

Otras arquitecturas y su relación con el diagrama Clean Architecture

Es un intento de integrar en una sola idea entendible las siguientes arquitecturas:

• Hexagonal Architecture (también conocida como Ports and Adapters) de Alistair Cockburn
• y adoptada por Steve Freman y Nat Pryce en su libro Growing Object Oriented Software.
• Onion Architecture de Jeffrey Palermo.
• Screaming Architecture de Uncle Bob.
• DCI de James Coplien y Trygve Reenskaug.
• BCE de Ivar Jacobson expuesto en su libro “Object Oriented Software Engineering: A Use-Case Driven Approach”.

Un paréntesis antes del Clean Architecture a detalle

From STUPID to SOLID code

(Principios)

STUPID

• Singleton Invasion: abusar de singletons (Ej: en AppDelegate y utilizarlo en todos lados)
• Tight Coupling: Difícil de reutilizar código, realizar pruebas y dar mantenimiento
• Untestability: :(
• Premature Optimization: Administrar los recursos, crítica objetiva, implementación eficiente vs. eficaz vs. ideal
• Indescriptible Naming: Falta de claridad
• Duplication: Evitar el DRY

SOLID

• Single Responsibility: Una clase debe tener una sola razón de existir y debe hacer una sola cosa
• Open / Close: Todo código debe ser abierto para extensión pero cerrado para modificación
• Liskov Substitucion: Todas las clases padre se pueden sustituir donde se tienen las clases hijas y no afectará el comportamiento, debe ser transparente
• Interface Segregation: Hay que hacer interfaces. Generar protocolos por categoría para evitar tener que implementar todos los métodos por dependencia
• Dependency Inversion: Depender de abstracciones y no de concreciones.

Medida universal de la calidad de código

(WTFs / minuto)

Code review de un buen código:

WTF, WTF

...