Please enable JavaScript.
Coggle requires JavaScript to display documents.
Arquitecturas de software - Coggle Diagram
Arquitecturas de software
Capas
Características
La capa de presentación solo se preocupa por presentar la información de forma agradable al usuario, pero no le interesa de donde viene la información ni la lógica de negocio que hay detrás, en su lugar, solo sabe que existe una capa de negocio que le proporcionará la información Por otro lado.
Por otra parte, la capa de negocio solo se encarga de aplicar todas las reglas de negocio y validaciones, pero no le interesa como recuperar los datos, guardarlos o borrarlos, ya que para eso tiene una capa de persistencia que se encarga de eso.
La capa de persistencia es la encargada de comunicarse a la base de datos, crear las instrucciones SQL para consultar, insertar, actualizar o borrar registros y retornarlos en un formato independiente a la base de datos.
El rol principal de la capa de base de datos es el de manejar el acceso y la gestión de los datos de la aplicación, gestión de consultas, integridad de datos, comunicándose generalmente a través de un ORM (Object-Relational Mapping) o comandos SQL directos.
Descripción
Divide una aplicación en capas lógicas, como la capa de presentación, la capa de lógica de negocio y la capa de acceso a datos. Este patrón promueve la modularidad y la escalabilidad, puede tener varias capas y se pueden modificar dependiendo la complejidad y lo que se requiera.
Ventajas
:check: Cada capa se puede desarrollar, probar y mantener de forma independiente, lo que facilita la gestión del código.
:check:Las capas inferiores pueden ser reutilizadas en diferentes aplicaciones.
:check:Oculta la complejidad de las capas inferiores a las superiores, promoviendo una mayor abstracción.
:check:Los cambios en una capa suelen tener un impacto limitado en otras capas, facilitando el mantenimiento.
Desventajas
:red_cross: La comunicación entre capas puede introducir sobrecarga y afectar el rendimiento del sistema..
:red_cross: A medida que aumenta el número de capas, la complejidad del sistema también aumenta.
:red_cross:Si no se diseña correctamente, puede haber un fuerte acoplamiento entre las capas.
:red_cross:En sistemas pequeños, puede resultar en una sobreingeniería al introducir capas innecesarias.
Arquitectura de Microservicios
Descripción
Descompone una aplicación en servicios pequeños e independientes que se comunican entre sí a través de APIs. Esto mejora la escalabilidad, la flexibilidad y la facilidad de mantenimiento.
Características
Un Microservicio es un pequeño programa que se especializa en realizar una pequeña tarea y se enfoca únicamente en eso
En una arquitectura de Microservicios se busca desmenuzar una gran aplicación en muchos y pequeños componentes que realizar de forma independiente una pequeña tarea de la problemática general.
Los Microservicios son desplegados de forma independiente y están desacoplados entre sí. Además, deben ser accedidos por medio de protocolos de acceso remoto, como colas de mensajes, SOAP, REST, RPC, etc.
Ventajas
:check: Permite utilizar diferentes tecnologías para cada microservicio.
:check:Cada microservicio puede ser desplegado de forma independiente.
:check:Un fallo en un microservicio no afecta a toda la aplicación.
:check:Los microservicios son más pequeños y fáciles de comprender.
Desventajas
:red_cross: Aumenta la complejidad de la arquitectura en general.
:red_cross:Requiere una gestión cuidadosa de la comunicación entre servicios.
:red_cross:La distribución de la aplicación puede dificultar la depuración y el monitoreo.
:red_cross:Puede ser difícil mantener la consistencia de los datos entre diferentes microservicios.
Modelo-Vista-Controlador (MVC)
Caracterísitcas
El modelo se considera la capa que se encarga de los datos y, por consiguiente, es la capa que envía la información al controlador.
El controlador, que hace referencia al encargado de recibir esta información u órdenes, para luego remitirlas a la tercera y última capa llamada vista. el controlador actúa como intermediario entre los otros componentes, es decir, entre el modelo y la vista.
La vista es lo que se considera como el front-end que, en otras palabras, es la representación visual de esos datos, lo que da como resultado la interfaz gráfica de usuario.
Ventajas
:check: Fácil organización: Su uso de únicamente 3 componentes lo vuelve bastante fácil de organizar.
:check: Adaptabilidad: Es capaz de adaptarse a diferentes frameworks, como Angular o Django.
:check: Escalabilidad: Permite que cada componente se desarrolle de forma independiente, facilitando su escalado.
:check:Facilita la creación de pruebas unitarias para cada componente, lo que mejora la calidad del software.
Desventajas
:red_cross: Puede requerir una curva de aprendizaje más pronunciada para nuevos desarrolladores.
:red_cross: En aplicaciones muy grandes y complejas, puede introducir cierta sobrecarga.
:red_cross: Si no se implementa correctamente, puede haber un acoplamiento fuerte entre los componentes.
:red_cross: Requiere el uso de herramientas específicas para gestionar la complejidad de la aplicación.
Descripción
Divide una aplicación en tres componentes principales: el Modelo (que maneja los datos y la lógica de negocio), la Vista (que se encarga de la presentación y la interfaz de usuario) y el Controlador (que coordina las interacciones entre el Modelo y la Vista).
Arquitectura Hexagonal (puertos y adaptadores)
Ventajas
:check: Separación de responsabilidades: Separa claramente las responsabilidades de la lógica de negocio de las responsabilidades de la infraestructura.
:check: Facilidad de prueba: Facilita la escritura de pruebas automatizadas para la lógica de negocio.
:check: Flexibilidad: Permite una mayor flexibilidad en la elección de tecnologías y herramientas.
:check: Escalabilidad: Permite escalar la aplicación en diferentes niveles, como la lógica de negocio o la infraestructura.
:check: Mantenibilidad: Facilita el mantenimiento de la aplicación a lo largo del tiempo, ya que la separación de responsabilidades hace que sea más fácil entender y actualizar diferentes componentes de la aplicación.
Descripción
Separa la lógica de negocio del código de infraestructura, permitiendo que la aplicación sea independiente de las tecnologías y las interfaces externas.
Características
Dominio: La capa en la que se define la lógica de la aplicación. Solo interactúa consigo mismo.
Aplicación: Aquí se implementa la lógica puede interactuar con Dominio y consigo mismo.
Infraestructura: Ubicación de los elementos de conexión con servicios externos. puede interactuar con aplicación y consigo mismo.
Desventajas
:red_cross:Aumenta la complejidad de la arquitectura en general.
:red_cross: Requiere una gestión cuidadosa de la comunicación entre servicios.
:red_cross:La distribución de la aplicación puede dificultar la depuración y el monitoreo.
:red_cross: Requiere una configuración más detallada de los puertos y adaptadores.
Arquitectura Orientada a Servicios (SOA)
Ventajas
:check: Reducción del plazo de comercialización: Los desarrolladores reutilizan servicios en diferentes procesos empresariales para ahorrar tiempo y dinero.
:check: Mantenimiento eficiente: Es más fácil crear, actualizar y corregir errores en servicios pequeños que en bloques grandes de código en aplicaciones monolíticas.
:check: Excelente capacidad de adaptación
La SOA se adapta de mejor manera a los avances tecnológicos. Puede modernizar sus aplicaciones de forma eficiente y rentable.
Descripción
Basada en la creación y el uso de servicios independientes que se pueden reutilizar en toda la aplicación. Esto promueve la interoperabilidad y la flexibilidad.
Caracterísitcas
Cada servicio expone una interfaz bien definida que describe las operaciones que puede realizar y los datos que puede intercambiar. Estas interfaces suelen estar basadas en estándares como SOAP o REST.
Para que un servicio sea considerado un Web Service, debe de publicar un WSDL (Web Services Description Language),
Los componentes de una aplicación SOA se construyen como servicios individuales, que pueden ser desarrollados, desplegados y gestionados de forma autónoma.
Por el contrario, SOA promueve la construcción de servicios que hagan una sola tarea, lo que hace que en lugar de tener 1 servicio que haga 10 cosas, mejor hacemos 10 servicios que hagan 1 cosas.
Desventajas
:red_cross: La arquitectura SOA no se caracteriza por el performance, pues la comunicación por la red y la distribución de los servicios agrega una latencia significativa en la comunicación.
:red_cross: SOA no se lleva con grandes volúmenes por petición, por lo que para procesar mucha información es recomendable utilizar otras tecnologías.
:red_cross: Para que SOA pueda ser implementado correctamente, es necesario crear un Gobierno que ponga orden sobre el uso y la creación de nuevos servicios, lo que puede representar una carga adicional a la empresa.
:red_cross: Debido a que SOA es una arquitectura distribuida, es necesario implementar estrategias de falla, pues se incrementa el número de puntos de falla.