Buenas prácticas para el análisis de un aplicativo orientado a servicios.
El documento presente, muestra las buenas prácticas para elaborar un aplicativo con una arquitectura orientada a servicios.
La receta propuesta por varios arquitectos de software plantea los siguientes pasos:
1. Análisis del flujo comercial del sistema.
2. Identificación de necesidades en la capa de infraestructura.
3. Identificación de los puntos neurálgicos y servicios macros en el flujo comercial.
4. División de módulos y creación de capas de inyección funcional de dependencia.
5. Exposición de contratos de los servicios macros.
Bien este análisis se detalla:
1. Análisis del flujo comercial del sistema.
En esta parte se debe identificar a todos los stackeholders , esto indica a todos los participantes del proyecto como tal; y mapear el flujo de la información.
Es importante considerar que todas las actas generadas en las reuniones sean puntuales en cuanto al origen y generación de la información como el proceso que se requiere para llegar a su destino.
Un modelo de ejemplo podría ser.
2. Identificación de necesidades en la capa de infraestructura
Bien una vez logrado un modelo similar al anterior se requiere ver que servicios corporativos tenemos a la manos para completar el trabajo, por ejemplo:
- Servicios de autenticación como card-space (dentro de una institución grande es vital).
- Servicios de transformación de datos (por ejemplo transformación de numero de cuenta a formatos comerciales).
- Servicios específicos (como el consumo de los datos del cliente atravez de un CRM).
- Servicios de contingencia (gestores de persistencia de datos).
En fin un pool de servicios corporativos con los cuales puede trabajar un aplicativo.
3. Identificación de los puntos neurálgicos y servicios macros en el flujo comercial.
Bien ahora que tenemos todos los recursos para construir nuestro aplicativo, es el momento de llenar las hojas de nuestro libro con los puntos neurálgicos, los mismos pueden ser identificados de la siguiente manera:
- Un punto neurálgico puede ser un punto en el flujo comercial en el cual se realiza algún tipo de especial transformación de la información.
- Un punto neurálgico puede involucrar la toma de decisiones por parte del usuario, para continuar con el flujo comercial
En fin un punto neurálgico se definirá por la relevancia semántica que el mismo le otorga al sistema.
Una vez conceptuado todos los puntos neurálgicos es hora de solucionarlos, para los mismo se puede seguir los siguiente pasos:
- Agrupar por afinidad todos los puntos.
- Realizar el análisis de los mismos y proponer una solución tecnológica.
- Una vez propuesta la solución realizar un contrato con el usuario, proponiéndoles dicha solución como un servicio a prestarle. (por ejemplo envio de mail’s de notificaciones, elaboración cálculos financieros por web, etc).
4. División de módulos y creación de capas de inyección funcional de dependencia.
Hasta aquí llegamos a finalizar el análisis general de nuestra solución, es momento de convertirlo en software; para lo mismo podemos considerar:
- Cada servicio macro que se preste al usuario se conceptuara como un modulo a resolver.
- Los requerimiento no funcionales, deben ser agrupados en capas comunes; por ejemplo el consumo de información de una BD.
- Es importante que cada modulo deba tener estructurado en su capa de lógica de negocios interfaces (a nivel POO) de las entidades más genéricas del modulo.
- Para relacionar un modulo con otro debemos implementar una capa de inyección de dependencias.
Bajo estas consideraciones podemos obtener un modelo similar a este (grafico obtenido de https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi7-LQv-yVGXteBt2_STbip9pyaU8CHjY-ZEcCOFNIz0InzRfI1YQRqa0Yzp98DtKYuXqhTnp9BvesxblsRkVDyaFokZC8Zd1XevuQYqu4DcvLSD1szOydlirKPJ5XHOqKAjG5cigaRG-g/s1600-h/EAI-02.jpg):
En donde Bussines Logic respresenta los módulos generados en nuestro análisis, presenta una interfaz de comunicación, si se está usando teconologia Microsoft es recomendable exponer dichas interfaces mediante un servicio WCF.
La capa vertical Persistency Area pues será nuestra capa de acceso a datos, se debe considerar seriamente usar un gestor de persistencia como Entity Framework.
Exchange Area se propone como la capa de inyección de dependencia funcional , en donde se podrán comunicar todos nuestros servicios expuestos mediante contratos definidos. Es importante mencionar que esta capa no permite independizarnos del manejo de la comunicación y serializacion , que para todo desarrollador es un trabajo muy pesado.
Cabe mencionar que en el grafico expuesto se debe considerar consumir los servicios corporativos por la capa Exchange Area.
Finalmente la capa UI (que se encuentra en rojo) solo debe depender de la capa Exchange Area; y es en donde presentamos al usuario sus interfaces a nivel web o desktop.
Usando Visual Studio, pues tendríamos exactamente 3 proyectos para las capas de inyección de dependencia, persistencia y capa de presentación. Y generamos un proyecto por cada componente (modulo) de lógica de negocios.
5. Exposición de contratos de los servicios macros.
Bien una vez realizado este trabajo pues nos toca realizar el análisis de la capa roja la interfaz de usuario; ya que para el usuario final será esta el criterio de evaluación de funcionalidad del sistema, básicamente la misma debe presentar las siguientes características:
- Debe ser amigable.
- Debe exponer claramente cada servicio, y dar a conocer al usuario cuando se está consumiendo un servicio; y cuando se hace un traslado de la información generada a otro servicio.
- Dentro de esta capa se debe considerar las plantillas de envió de mail’s y cualquier diseño a exponerse al usuario.
En caso de contar con IU complejas se recomienda colocarlas dentro de una solución con varios proyectos.
Una última recomendación para culminar su trabajo es documentar todo el código, para potenciar el uso de los servicios; mediante el inteligencie de los IDE’s (la mayoría actualmente tiene medios de desplegar la documentación adjunta al codigo).
