Arquitectura de Software: Adaptación y Escenarios de Uso

Clase 13 de 24 • Fundamentos de Arquitectura de Software (2018)

El reto que tienes es tomar un sistema conocido (del trabajo, algún proyecto propio o un sistema que hayas usado del que conozcas su arquitectura).

Describir qué problemas resuelve y cuáles son sus requerimientos no funcionales.

Si tuvieras que hacer de este sistema un “producto reutilizable” en otros escenarios:

¿Cómo cambiaría su arquitectura? ¿En qué otro escenario debería repensarse completamente? ¿En qué otros escenarios se mantendría?

compártenos en el sistema de discusiones.

Alejandra Yepes

student•

Sistema de información de Cargue Masivo Este sistema corresponde a una aplicación de carga masiva de Documentos, que se realiza en tiempo real, mediante una aplicación Web, en la cual se tenia definida una Arquitectura basada en un modelo Vista Controlador, allí, se contaba con un modelo en el cual se implementaron las reglas de negocio de la compañía, que corresponde a las casticistas de validaciones, según el los tipos de Servicio y los tipos de archivos, por otro lado se tenia implementada El modelo de las vistas, que correspondían al desarrollo de la interfaz de Usuario o capa de presentación y el controlador que realizaba la integración y validación entre las reglas de negocio y la capa de presentación. En esta compañía, se requería realizar una actualización, para mejorar la experiencia de usuario, aunque al mismo tiempo era necesario realizar actualización de la plataforma puesto que las versiones en las cuales estaba implementada la aplicación, ya no eran funcionales para los nuevos servicios y requerimientos del cliente, también era necesario cumplir con tiempos de respuesta para consultas y peticiones menor a un segundo, y un muy alto volumen de transaccional, se debía reutilizar el código de la lógica del negocio, por lo cual la

Arquitectura a implementar en este caso, fue: Un híbrido entre Arquitectura SOA, y Microservicios, La logica de negocio se mantendría, para lo cual lo que se realizo fue: El Front o capa de presentación seria implementado con un Framework JSF con primefaces, versión 6.2 y Primefaces Extensión 6.2.8, un fremawork ligero y muy facil de implementar, puesto que el cambio de arquitectura y actualización debía realizarse en tan solo 6 meses. Para el control de las vistas se apoyaría con un Bean controler. Desde alli se soportarían las validaciones básicas de los Formularios que no hacen parte de la lógica del negocio. La Lógica del negocio estaría soportada desde la capa de Servicios, realizando la implementación de Servicios y Microservicios REST con la aceptación de JSON. Los microservicios estarían dispuestos para la interacción con datos (Modo consulta) Desde los servicios se realizaría el mayor re-uso de Código de la lógica del negocio. Esto le permite a las organizaciones, implementar y actualizar aplicaciones en el menor tiempo posible si tener que hacer una construcción desde cero. Y finalmente la Capa de presentación podrá interactuar con la capa de Servicios por medio de una pasarela encargada de la comunicación entre estos.

¿En qué otro escenario debería repensarse completamente? Considero que la Arquitectura se debe replantear cuando la funcionalidad de los sistemas están llegando a su capacidad máxima de funcionalidad, constitucionalidad, tiempos muy largos de respuesta en las consultas, actualización en las versiones de la plataforma, porque las que se tienen no cuentan con nuevas funcionalidades, mejorar la experiencia al usuario, basada en las estrategias y normas del País, otros factores como: la Capacidad de Uso de los datos o también cuando requiere de integraciones con con otros sistemas y la estructura actual no lo permite, bien sea por compatibilidad o porque el modelo actual es limitado.

¿En qué otros escenarios se mantendría?

Pienso que esta se debe mantener siempre y cuando cumpla con los requerimientos funcionales del sistema o las características básica de el.

Que sea estable, escalable, sostenible en el tiempo (Mantenimiento-soporte), usabilidad, accesibilidad a la data, y que se pueda integrar si se requiere.