Overview
¿Por qué utilizar una arquitectura limpia?¶
Más allá de utilizar una arquitectura limpia, hemos detectado que la empresa posee un amplio espectro de equipos y tecnologías para el desarrollo donde se evidencian las prácticas, técnicas y conocimientos que poseen los equipos para desarrollar y resolver las necesidades que presenta el negocio. Por lo que al ver estas diferencias se definió estandarizar una arquitectura de software, que sirva para que todos los desarrollos que se producen en la empresa "hablen el mismo idioma" y poder ser mantenibles en el tiempo. Para eso se implementó en una primera instancia platform el cual disponibiliza una arquitectura común, aunque incompleta o no estandarizada.
El paso que estamos dando, con la implementación de la nueva arquitectura, es disponibilizar una arquitectura de software estándar para toda la empresa, para asegurarnos control, calidad, agilidad y mantenibilidad en el tiempo. Al definir la arquitectura estándar se puede hablar el mismo idioma en todos los equipos. Además que podemos capacitar a los nuevos colaboradores y entregar valor a sus equipos rápidamente.
Contestando a la pregunta, ¿por qué utilizar una arquitectura limpia?
- Es aplicable a múltiples tecnologías (dotnet, golang, java).
- Desacoplamiento - cada capa es independiente de las demás por lo que podríamos reemplazarla
- Mantenibilidad - Mayor flexibilidad para añadir o remover funcionalidades del software
- Diseño basado en componentes con responsabilidades bien definidas
- Testing - oportunidad de testear de manera rápida y fácil.
- Calidad - producto sólido, de calidad y escalable
¿Qué es Clean Architecture?¶
Clean Architecture es un término introducido por Rober C. Martin. Él recopiló los modelos de capas más utilizados en una versión mejorada a la que llamó Clean Architecture
A continuación te presento 5 principios sobre los cuales se basó:
-
Es independiente de cualquier framework. 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 pueden sobrevivir individualmente sin necesidad de externos.
-
Testeable. Entre más pura sea una función, clase, módulo etc. 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. Lee este artículo para que entiendas mucho más sobre los efectos colaterales y funciones puras. (Importante de leer para completar la lección). Cada módulo tanto de UI, base de datos, conexión a API Rest, etc. debe ser capaz de ser testeado individualmente.
-
Independiente de la Interfaz de Usuario. Uno de los componentes que sufren cambios más 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 ser sustituida por otra. Por ejemplo. Cambiar una UI Móvil por una en modo consola.
-
Independiente de la base de datos. Así como el punto anterior, esta capa debe ser tan modular que es posible agregarle múltiples fuentes de datos, e incluso múltiples fuentes del mismo tipo de datos. Por ejemplo, manejar varias bases de datos: MySQL, PostgreSQL, Redis, etc.
-
Independiente de cualquier elemento externo. Si en algún punto nuestro sistema necesita de una librería, otro sistema o cualquier otro 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.
Estos conceptos se pueden diagramar de la siguiente manera.
Este diagrama es un modelo teorico, por lo que cada dependiendo de la tecnología se puede implementar de diferente manera.