Arquitectura Limpia Robert C Martin Pdf
Clara Zellinger
Es muy difcil resumir el concepto de dependencia / acoplamiento de software. Una de las maneras ms formales que conozco para medir y cuantificar la dependencia de cada una de las piezas del software es la "conasence" o "Conacimiento"?.
En la primera foto podemos decir que todos los utensilios estn acoplados entre si, porque para mover las tijeras tenemos que mover el bolgrafo y para mover el bolgrafo tenemos que mover la grapadora...
Las arquitecturas limpias buscan reducir el acoplamiento organizando las piezas en 3 grandes bloques: Dominio, Aplicacin y Presentacin. La dependencias se organizan de forma que las capas ms centrales no saben nada de las capas exteriores.
En esta ltima capa tendremos toda la lgica necesaria para presentar nuestra lgica de negocio al cliente final. Podramos escribir una aplicacin en React, una aplicacin en Vue o incluso un asistente de voz escrito en javascript.
Nuestra lgica de negocio y nuestros objetos de dominio son iguales independientemente de la tecnologa 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. Adems podemos escribir tests 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 estn acoplados a la lgica de negocio y la lgica de negocio a su vez es independiente de la presentacin.. Esto hace que cuando tengamos que mantener una aplicacin grande tengamos muchsimo ms claro qu nudos hay que deshacer para reemplazar la grapadora por una ms moderna.
Estoy seguro de que si te dedicas a programar, conoces a Robert "Uncle" Martin. Su libro Clean Code es uno de los ms recomendados en la lista de libros que todo desarrollador debera leer. Martin, con sus cosas buenas y malas, es uno de los desarrolladores ms influyentes del panorama ingenieril. Fuerte defensor de TDD, de la cobertura de tests y otras buenas prcticas, y adems cuenta con muchas personas que siguen sus enseanzas a rajatabla.
El cdigo limpio es aquel cdigo que est estructurado de forma compresible, que es claro en sus intenciones, fcil de leer, que es fcilmente mantenible y que est testeado. En el libro se van dando algunas ideas para conseguir escribir cdigo limpio, hablando de principios SOLID, de la importancia de dar nombres a variables y clases etc. En GenbetaDev ya hemos hablado del libro y de sus ideas en alguna ocasin
Aunque seamos capaces de escribir cdigo limpio, podemos encontrarnos que al crecer nuestro sistema, la arquitectura del mismo sea un lastre. Y es que no es lo mismo escribir cdigo limpio para un proyecto sencillo, que para un proyecto complejo compuesto de varios componentes obligados a cooperar. A veces las arquitecturas son demasiado complejas, nos obligan a repetir cdigo, o nos hacen tener demasiadas dependencias entre componentes, causndonos muchos problemas.
Si utilizis programacin orientada a objetos, seguro que conocis los conceptos de cohesin y acoplamiento. Esos conceptos tambin pueden aplicarse de forma parecida a los componentes de un sistema, ya sean dlls o archivos jar, estos tienen que cooperar unos con otros. Y la manera en la que cooperen, pueden hacer un sistema fracasar. Pero si seguimos una serie de principios para controlar estas dos variables, nuestra arquitectura ser ms limpia y manejable.
The Reuse/Release Equivalence Principle: que nos dice que los componentes deben poder ser desplegados de forma independiente sin afectar a los dems. Las clases, o cdigo que van en ese componente, deben tener una relacin, y por tanto deben poderse desplegar de forma conjunta.
The common closure principle: se podra decir que hablamos del principio de responsabilidad nica (SRP) aplicado a componentes. La idea es agrupar clases que puedan cambiar por la misma razn en un solo componente. Si tenemos que hacer un cambio, y hay que tocar varios componentes, esto supondr tener que desplegarlos todos, en lugar de slo uno.
The common reuse principle: este principio nos habla de evitar a aquellos que utilizan un componente depender de cosas que no necesitan. Si un componente depende de otro, hay que intentar que sea porque necesita todas las clases que lo componen. Lo contrario nos obligar a trabajar ms cuando nos toque hacer el despliegue. De esta manera ser ms fcil reutilizar componentes.
Conseguir cumplir estos tres principios a la vez es algo bastante difcil, por lo que a veces hay que aceptar compromisos. Por ejemplo es comn sacrificar un poco la reusabilidad, para conseguir que los componentes sean fciles de desplegar.
The Acyclic Dependencies Principle: si trazamos lneas entre los componentes para representar las dependencias entre ellos, tenemos que intentar que no existan ciclos. Es decir, que el cambio en un componente, no acabe desencadenando en la necesidad de hacer cambios en cadena en los dems componentes, que obliguen a volver a modificar el componente inicial. Cuando eso sucede, es difcil conseguir una versin estable del sistema, ya que hay que hacer multitud de cambios en los distintos componentes hasta que todo vuelve a funcionar.
The stable dependencies Principle: todo sistema tiende a cambiar y evolucionar, pero no todos los componentes cambian con la misma frecuencia, ni es igual de fcil modificarlos. Este principio nos dice que un componente que cambia a menudo no debera depender de otro que es difcil modificar, ya que entonces ser tambin difcil de modificar.
The stable Abstractions Principle: este principio nos dice que si un componente de nuestro sistema va a cambiar poco ya que es difcil modificarlo, debe estar compuesto mayoritariamente por interfaces y clases abstractas. De esta manera el componente ser fcilmente extensible, y no afectar tanto al resto de la arquitectura.
Independiente de la base de datos. Deberamos poder cambiar de Oracle, a SQL Server, a MongoDB, a Casandra o a cualquier otra base de datos sin que afectara demasiado a nuestro sistema.
Las entidades son las que incluyen las reglas de negocio crticas para el sistema. Estas entidades pueden ser utilizadas por distintos componentes de la arquitectura, por lo que son independientes, y no deben cambiar a consecuencia de otros elementos externos.
Una entidad deber englobar un concepto crtico para el negocio, y nosotros tendremos que separarlo lo ms posible del resto de conceptos. Esa entidad recibir los datos necesarios, y realizar operaciones sobre ellos para conseguir el objetivo deseado.
En este caso nos encontramos con las reglas de negocio aplicables a una aplicacin concreta. Estos casos de uso siguen un flujo para conseguir que las reglas definidas por las entidades se cumplan. Los casos de uso, solo definen como se comporta nuestro sistema, definiendo los datos de entrada necesarios, y cual ser su salida. Los cambios en esta capa no deberan afectar a las entidades, al igual que los cambios en otras capas externas no deberan afectar a los casos de uso.
Es importante que no pensemos en como los datos que genera un caso de uso sern presentados al usuario. No deberemos pensar en HTML, o en SQL. Un caso de uso recibe datos estructurados y devuelve ms datos estructurados.
Los datos generados por los casos de uso y las entidades, tienen que transformarse en algo entendible por la siguiente capa que los va a utilizar y de eso se encarga esta capa. Pensando en MVC por ejemplo, los controladores y las vistas, perteneceran a esta capa, y el modelo, seran los datos que se pasan entre los casos de uso y los controladores para luego poder presentar las vistas.
Una frontera (o como dicen los aglosajones, boundaries) es una separacin que definimos en nuestra arquitectura para dividir componentes y definir dependencias. Estas fronteras tenemos que decidir dnde ponerlas, y cundo ponerlas. Esta decisin es importante ya que puede condicionar el buen desempeo del proyecto. Una mala decisin sobre los lmites puede complicar el desarrollo de nuestra aplicacin o su mantenimiento futuro.
Por ejemplo, podemos sentirnos tentados de pensar que las reglas de negocio deben poder guardar informacin directamente en la base de datos. Como ya hemos visto antes, la base de datos es un detalle, as que esto deberamos evitarlo. En ese punto deberamos trazar una frontera. Nuestras reglas de negocio, se comunicaran siempre con una interface, sin saber nada sobre la base de datos. La base de datos en cambio, si sabr cosas sobre las reglas de negocio, ya que tiene que transformar los datos en sentencias SQL que puedan almacenar la informacin.
Otra ventaja adicional de este enfoque, es que podemos retrasar ciertas decisiones. Podemos empezar a desarrollar todas nuestras reglas de negocio, sin tener en cuenta su persistencia, ya que esa parte se realiza a travs de una interface. Primero podemos utilizar objetos en memoria, y segn avancemos, ir aadiendo sistemas ms sofisticados. Al final podremos elegir entre usar una base de datos relacional, NoSQL, o incluso guardar la informacin en archivos.
En el esquema de arquitectura limpia que hemos visto anteriormente, podemos ver dnde se han trazado las fronteras o lmites. Entre entidades y casos de uso, hay una frontera. Lo mismo con los adaptadores de interface, o los frameworks y drivers. Las fronteras son importantes, porque aadirlas cuando no las necesitamos pude crearnos muchos problemas, pero no aadirlas cuando las necesitamos pude generar otros tantos (aadirlas despus, es siempre es mucho ms costoso).
Esta regla es muy importante, ya que sin ella, nuestra arquitectura no sera ms que un bonito diagrama. Las capas interiores de una arquitectura limpia, no deben saber nada de las capas exteriores. Por ejemplo la capa de entidades, no puede saber de la existencia de los casos de uso, y los casos de uso no deben saber nada de la existencia de los adaptadores de interface. As las dependencias estn controladas y van siempre en un solo sentido.
4a15465005