Clean Architecture
Last updated
Last updated
Clean Architecture es un nombre popularizado por Robert Cecil Martin, que se basa en la premisa de estructurar el código en capas contiguas, es decir, que solo tienen comunicación con las capas que están inmediatamente a sus lados. La idea es que cada nivel debe realizar sus propias tareas y se comunica únicamente con sus niveles inmediatamente contiguos.
Todo esto, con el fin de hacer el código mucho más entendible en el presente y futuro, testeable y fácil de integrar.
El principal objetivo de una arquitectura limpia es la capacidad de separar el código en sus diferentes responsabilidades.
Las entidades son los modelos definidos que interactuarán en el sistema. Estas deben ser lo suficientemente abstractas para ser usadas por múltiples aplicaciones en el negocio.
Contienen las reglas que le dan sentido a la aplicación. Los casos de uso dirigen el flujo a las entidades y las orquestan para cumplir con el negocio.
Esta es la capa intercesora que convierte los datos extraídos por la interfaz de usuario y la capa de datos en el formato más conveniente para los casos de uso, también esta capa se encuentran los controladores, los presentadores y lo modelos de vista. Acá podríamos tener todo el patrón MVC.
En esta capa van todos los detalles, tanto para mostrar datos en la UI como para obtener los datos requeridos.
Tambien podríamos hacer coincidir el modelo básico de capas que consiste en
Presentation Layer
Business Logic Layer
Data Layer
Clean Architecture es un término introducido por Rober C. Martin, mejor conocido como Uncle Bob o Tío Bob. Él recopiló los modelos de capas más utilizados en una versión mejorada a la que llamó Clean Architecture.
A continuación, presento 5 principios sobre los cuales se basó:
La arquitectura limpia debe ser capaz de aplicarse a cualquier sistema sin importar el lenguaje de programación o las librerías que utilice. Las capas deben quedar tan bien separadas que puedan sobrevivir individualmente, sin necesidad de externos.
Entre más pura sea una función, clase o módulo más fácil será predecir el resultado a obtener. Cuando hablamos de que algo sea puro nos referimos a que no tenga efectos colaterales. Cada módulo, tanto de UI, base de datos, conexión a API Rest, etc., se debe poder testear de forma individual.
Uno de los componentes que sufren cambios constantemente es la interfaz de usuario. La UI debe ser capaz de cambiar sin alterar todo el sistema y, si vamos más allá, esta capa debería vivir tan independiente que podría ser desensamblada y sustituida por otra. Por ejemplo, cambiar una UI Móvil por una en modo consola.
Así como en el punto anterior, esta capa debe ser tan modular que sea posible agregarle múltiples fuentes de datos, e incluso múltiples fuentes del mismo tipo de datos. Por ejemplo, manejar varias bases de datos como MySQL, PostgreSQL, Redis, etc.
Si en algún punto nuestro sistema necesita de una librería, otro sistema o cualquier elemento a conectar, debería ser fácilmente ensamblado y también debería ser modularizado. De hecho, para el sistema esta capa externa debería ser transparente.
