Arquitectura de software: la diferencia entre arquitectura y diseño

Mucha gente no sabe cuál es la diferencia entre arquitectura y diseño de aplicaciones. Incluso los propios desarrolladores a menudo no pueden analizar una línea de código y pueden confundir los elementos de la arquitectura de la aplicación con los elementos de diseño. Como desarrollador, me gustaría explicar estos conceptos, así como la diferencia entre el diseño y la arquitectura de la aplicación. Además, les mostraré por qué es importante que los desarrolladores entiendan al menos un poco sobre arquitectura de software y mucho sobre diseño. Entonces empecemos.

Definición de arquitectura de software

En términos simples, la arquitectura de software es el proceso de convertir las características del software, como flexibilidad, escalabilidad, implementabilidad, reutilización y seguridad, en una solución estructurada que cumpla con los requisitos técnicos y comerciales. Esto plantea la siguiente pregunta: ¿qué características del software pueden influir en la preocupación de la arquitectura del software? Además de las características técnicas, también hay muchos parámetros que cumplen principalmente con los requisitos comerciales o de funcionalidad.

Características de la arquitectura de software

Como ya expliqué, las características del software ayudan a comprender los requisitos del software y las expectativas con respecto a él a nivel funcional y técnico. Entonces, si el propietario de un producto dice que tiene que competir en un mercado que cambia rápidamente, entonces necesita adaptar rápidamente su modelo de negocio. El software debe ser “ fácil de expandir su funcionalidad, estar compuesto por bloques y ser fácil de mantener ” si queremos que esté preparado con alta calidad ya tiempo. Si eres arquitecto de software, debes saber que los principales parámetros para ti serán la calidad del trabajo y la alta tolerancia a fallas, la escalabilidad y la confiabilidad.. Y ahora, después de haber decidido todos los parámetros principales, su gerente le dice que el presupuesto para este proyecto es limitado. Aquí es donde entra en juego otro parámetro: la  factibilidad.

Puede encontrar una lista completa de parámetros de software o las llamadas "características cualitativas" aquí.

Patrones de arquitectura de software

La mayoría de ustedes probablemente ya estén familiarizados con el término “ microservicios ”. Los microservicios  son una forma de modelar la arquitectura de software, junto con la arquitectura en capas, la arquitectura basada en eventos, la arquitectura sin servidor y muchas otras. Algunos de los patrones anteriores se describirán a continuación. El estilo de arquitectura de microservicio se hizo famoso después de que Amazon y Netflix lo adoptaran con éxito. Ahora, profundicemos en los detalles y analicemos los estilos arquitectónicos con más detalle.

** Advertencia: no confunda los estilos arquitectónicos con los patrones de diseño, como el patrón de diseño de fábrica o los adaptadores. Hablaré de ellos más tarde.

Estilo arquitectónico sin servidor

Este elemento es aplicable a las aplicaciones que utilizan servicios de terceros como solución para resolver el problema de la carga del servidor y del backend. La arquitectura sin servidor se divide en dos categorías principales. El primero es "backend como servicio (BaaS)", el segundo es "función como servicio (FaaS)". La arquitectura sin servidor lo ayudará a ahorrar tiempo en la verificación y corrección de errores de migración, así como en el manejo de tareas regulares del servidor.

El ejemplo más famoso de una API sin servidor es el servicio "Lambda" de Amazon AWS.

Puedes leer más sobre esto aquí .

Arquitectura impulsada por eventos

Esta arquitectura está ligada a productores de eventos y consumidores de eventos. La idea principal es separar las partes de su sistema para que cada parte se active cuando ocurra un evento interesante en la otra. ¿Difícil? Simplifiquemos. Imagina que estás creando un sistema para una tienda online y consta de dos partes: un módulo de compras y un módulo de ventas. Cuando un cliente realiza una compra, el módulo de compras activa un evento de "pedido pendiente". Dado que el módulo de ventas está interesado en este evento, monitoreará el proceso en caso de que sea llamado. Tan pronto como el módulo de ventas reciba este evento, ejecutará ciertas tareas o activará otro evento para continuar comprando productos de un proveedor específico.

Tenga en cuenta que el productor de eventos no sabe qué evento está siendo observado por qué consumidor de eventos. Además, otros consumidores no saben cuál de ellos está viendo qué evento. Por lo tanto, la idea principal es dividir las partes del sistema.

Si desea obtener más información sobre las arquitecturas basadas en eventos, siga el enlace .

Arquitectura de microservicios

En los últimos años, la arquitectura de microservicios se ha convertido en una de las más populares. Está construido sobre pequeños servicios modulares independientes, cada uno de los cuales resuelve un problema diferente o realiza una tarea única. Estos módulos interactúan a través de una API que está programada para cumplir con un propósito comercial específico. Ahora mira la imagen y entenderás todo.

Diseño de software

La arquitectura es el esqueleto y la infraestructura en capas del software, mientras que el diseño del software es el diseño a nivel de código, como lo que hace cada módulo, la diversidad de clases, los objetivos de las funciones, etc.

Si es un desarrollador, debe conocer los principios de SOLID y comprender cómo un patrón de diseño debe resolver los problemas cotidianos.

Los principios de SOLID (Single Responsibility Principle, Open/Closed Principle, Loskov Substitution Principle, Interface segregation Principle, Dependency Inversion Principle)  son Responsabilidad Única, Abierto/Cerrado, Principio de Sustitución de Barbara Liskov, Principio de Separación de Interfaz y Principio de Inversión de Dependencia.

• El principio de responsabilidad única significa que cada clase trabaja en un solo objetivo, es responsable solo por él y cambia por una sola razón.
• Principio abierto/cerrado : una clase debe estar abierta a la extensión, pero cerrada al cambio. En pocas palabras, puede agregar una nueva funcionalidad a una clase, pero no puede editar la funcionalidad existente de una manera que entre en conflicto con el código que está utilizando.
• Principio de sustitución de Barbara Liskov: según este principio, el desarrollador debe respetar la herencia de tal manera que la lógica de la aplicación no se viole en ningún lugar. Por lo tanto, si la nueva clase "XyClass" se deriva de la clase principal "AbClass", la nueva clase debe repetir las funciones de la clase principal de tal manera que no cambien el comportamiento de la clase principal. Entonces puede usar fácilmente el objeto de clase XyClass en lugar del objeto de clase AbClass sin violar la lógica de la aplicación.
• Principio de separación de interfaces : es simple: una clase puede implementar muchas interfaces, escriba su código de tal manera que la clase nunca tenga que implementar una función que no sea importante para sus tareas. Conclusión: divida sus interfaces en categorías.
• Principio de inversión de dependencia : si alguna vez usó TDD para crear su aplicación, sabe lo importante que es dividir el código antes de probarlo y simularlo. En otras palabras, si una clase "por ejemplo: Compra" en particular depende de la clase "Usuarios", la configuración de los objetos de usuario debe iniciarse desde fuera de la clase "Compra".

Patrones de diseño

• El modelo de fábrica  es el patrón de diseño más utilizado en el mundo OOP porque le ahorra mucho tiempo en el futuro cuando necesite cambiar una de las clases que utilizó. Veamos un ejemplo:

Supongamos que desea implementar el modelo de clase Users(), puede utilizar uno de dos métodos:

1 - $usuarios = new Users();

2 - $usuarios = DataFactory::get('Users');

Elegiría la segunda, por dos razones principales, por encima de todas las demás. Primero, cambiar el nombre de la clase de "Usuarios" a "UserData" es solo un cambio en un lugar, dentro de la base de fábrica; de lo contrario, su código sigue siendo el mismo. En segundo lugar, si aparecen parámetros como Users($connection) en la clase Users, solo tendrá que realizar cambios en un lugar y no en todas las funciones que utilizan objetos de la clase Users. Así que si crees que la primera opción es mejor, piénsalo de nuevo.

• Un adaptador (patrón de diseño)  es uno de los patrones de diseño estructural. Mirando el nombre, puedes entender que este modelo hace que el uso inesperado de la clase sea el esperado.

Imagina que tu aplicación funciona en la API de YouTube y para obtener un token de acceso, debes llamar a la función getYoutubeToken();

Así que ha llamado a esta función en 20 lugares diferentes en su aplicación.

Y luego, Google publica una nueva versión de la API, cambiando el nombre de la función a getAccessToken();

Ahora deberá buscar y cambiar el nombre de esta función en toda la aplicación, o crear una clase de adaptador, como se muestra en el siguiente ejemplo:

En este último caso, lo único que tienes que hacer es cambiar una línea, el resto de la aplicación seguirá funcionando como hasta ahora.

Recuerde que un arquitecto de software y un desarrollador de software son dos cosas diferentes. Los arquitectos de software generalmente trabajan con un líder de equipo experimentado que conoce bien las soluciones existentes, lo que lo ayuda a tomar las decisiones correctas en la etapa de planificación. El desarrollador de software debe estar familiarizado con el diseño de software y también debe tener conocimiento de la arquitectura de la aplicación para que el equipo pueda comunicarse fácilmente.

Fuente:

https://elsolitario.org/post/arquitectura-de-software-la-diferencia-entre-arquitectura-y-diseno/