Breve는 las arquitecturas limpias를 소개합니다.

En este artículo tratare de describir de forma muy breve y questá algo inexacta el concepto de arquitectura limpia en el contexto del software.

"Arquitectura limpia"es el título del libro de Robert C Martin en el que expone y desarrolla el concepto.

소프트웨어 아키텍처

Citando a Robert, "La arquitectura de un sistema de software es la forma en la que se organizan los componentes que lo forman y la forma en la que se comunican entre sí".

En proyectos pequeños como prácticas de clase la importancia de tener una buena arquitectura puede no ser muy evidencee pero a medida que los proyectos crecen se hace más y más claro la su importancia.

Uno de los mejores ejemplos que he visto para ilustrar esta importancia :



¿Qué nudos tienes que deshacer para separar la grapadora del resto de componentes?

Ahora mira esta imagen:



Pues con el software pasa lo mismo, sin entrar en detalles buscamos reducir **la dependsencia **de cada una de las piezas y que cada cosa esté en su lugar.

디펜덴시아

Es muy difícil resumir el concepto de dependsencia/acoplamiento de software. Una de las maneras más formales que conozco para medir y cuantificar la dependsencia de cada una de las piezas del software es la "conasence" o ¿"Conacimiento"? .

Resumiéndolo mucho podemos decir que "una pieza A dependse de una pieza B si cambios en la pieza B afectan de alguna forma a la pieza A"

En la primera foto podemos decir que todos los utensilios están acoplados entre si, porque para mover las tijeras tenemos que mover el bolígrafo y para mover el bolígrafo tenemos que mover la grapadora...

En la segunda foto este acoplamiento se reduce mucho y las tijeras sólo están acopladas al taco de post-it.

건축술 림피아스

Las arquitecturas limpias buscan reduceir el acoplamiento organizando las piezas en 3 grandes bloques: Dominio, Aplicación y Presentación. La Dependencias se Organizan de forma que las capas más centrales no saben nada de las capas exteriores.

도미니오

Es donde se definen nuestros objetos de negocio. Por ejemplo si estamos trabajando en una entidad bancaria, una hipoteca o 유엔 cliente Serían objetos de negocio.

Estos objetos se pueden representationar con clases y no tienen absolutamente ninguna Dependencia (no importan otros archivos).

export default class Mortgage {
    constructor(amount, years, rate) {
        this.amount = amount;
        this.years = years;
        this.rate = rate;
    }
}

export default class Client {
    constructor(name, age) {
        this.name = name;
        this.age = age;
    }
}

신청

Por encima del dominio tenemos las reglas de negocio. Estas reglas conocen los objetos de dominio y junto a estos definen nuestra lógica de negocio

Por ejemplo "No conceder préstamos a más de 20 años vista a personas mayores de 40 años"

/**
 * Esta función recibe como parámetro una hipoteca y un cliente y devuelve
 * true o false según se pueda conceder o no esta hipoteca. 
 *
 * Cambios en la clase hipoteca o en la clase Cliente pueden 
 * afectar a esta función y decimos que están acopladas.
 *
 * Siendo estrictos podemos decir que tenemos 
 * [conacimiento de tipo](https://connascence.io/type.html) 
 * en los parámetros
 *
 */
function checkIfMortageCanBeGranted(mortage, client) {
    if(client.age > 40 && mortage.years > 20) {
        return false;
    }

    // ... Asumimos que habría mas reglas de negocio

    // Finalmente devolvemos true para conceder la hipoteca
    return true;
}

프레젠타시온

En esta última capa tendremos toda la lógica necesaria para presentar nuestra lógica de negocio al cliente final. Podríamos escribir una aplicación en React, una aplicación en Vue o incluso un asistente de voz escrito en javascript.

Nuestra logica de negocio y nuestros objetos de dominio son iguales independientemente de la technología elegida para la vista y pueden ser utilizados por una app escrita en Angular, por una app escrita en Vue o por una app escrita en React. Además podemos escribir test unitarios que comprueben este comportamiento de forma totalmente aislada para verificar que los requisitos son correctos.

De nuevo, lo importante es que gracias a aplicar una arquitectura limpia tanto los objetos de dominio no están acoplados a la lógica de negocio y la lógica de negocio a su vez es independiente de la presentación.. Esto hace que cuando tengamos que mantener una aplicación grande tengamos muchísimo más claro qué nudos hay que deshacer para reemplazar la grapadora por una más moderna.

엔레이스

https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

https://www.amazon.com/Clean-Architecture-Craftsmans-Software-Structure/dp/0134494164

https://leanpub.com/pppsd