Este proyecto está constituido por un conjunto de módulos para gestionar productos de ahorro e inversión.
Tecnológicamente está basado en:
-
Spring Cloud
-
Spring Boot
-
Spring Integration
-
MongoDB
-
RabbitMQ
Esta aplicación incluye los siguientes proyectos:
| Proyecto | Información | Imágenes |
|---|---|---|
Microservicios de gestión de activos. |
||
Microservicios de gestión de carteras. |
||
Microservicios de gestión de entidades legales. |
||
Microservicios de servicios financieros. |
||
Microservicios de gestión de órdenes. |
||
Microservicios de integración con brokers. |
||
Microservicios de contratación. |
||
Microservicios de acuerdos marco. |
||
Microservicios de gastos y comisiones. |
||
Programador de tareas. |
||
Proxy. |
||
Pruebas de integración |
n/a |
|
Servidor de configuración. |
||
Frontend. |
||
Eureka. |
||
Repositorio de configuración. |
n/a |
|
Servidor de autenticación. |
Actualmente la aplicación cuenta con un modelo de dominio común para todos los módulos. La idea es desacoplar el modelo de los diferentes módulos y que simplemente intercambien los objetos de alto nivel (por ejemplo no queremos tener visibilidad de todos los módulos de los elementos que componen la cartera de un contrato). De este modo cada módulo estaría perfectamente desacoplado del resto y podría ser desarrollado con otro ciclo de vida independiente.
Como estoy en proceso de refactor la idea es definir las entidades en el módulo de domain-hateoas para reducir el acoplamiento, aunque esto aún está en la lista de cosillas por hacer.
La contratación está separada en dos módulos. Un gateway que simplemente provee de los servicios REST comunes y hace de dispatcher para encolar los mensajes en RabbitMQ.
Después tenemos el otro módulo (core) que procesa los mensajes obtenidos de RabbitMQ.
Esencialmente el flujo es sencillo:
-
El cliente invoca al gateway con un bean de tipo
ContractCreationDataque contiene toda la información necesaria para crear el contrato. -
El gateway traslada el bean a un canal de de entrada donde se definirá el flujo a través de DSL, por ejemplo parte de este flujo será controlar las validaciones.
-
Como parte del flujo DSL el gateway encolará la petición en RabbitMQ y se quedará esperando la respuesta (este proceso puede hacerse de forma síncrona para por ejemplo una contratación web o asíncrona por ejemplo para procesos batch).
-
El módulo core persistirá el contrato y devolverá el mensaje a RabbitMQ donde lo recogerá el gateway.
Posteriormente realizaremos una petición de aprobación del contrato a través del gateway. Esto generará un mensaje en la cola de aprobación que será procesado por el módulo insurance-contract-creation-core.
Una vez reciba el mensaje informará a los diferentes módulos registrados en el sistema para que realicen las operaciones necesarias de forma asíncrona:
-
Generación del portfolio
-
Generación de la documentación del contrato
-
etc.
Finalmente procesaremos la acción de recepción del pago inicial. Esto establecerá las fechas de las órdenes y encolará el mensaje para que se procese el pago.
Los diferentes mensajes que se procesarán de forma asíncrona, eso nos asegura por ejemplo que si un componente no está disponible en un determinado momento no afectará al proceso de contratación/aprobación. También facilita la integración de módulos adicionales ya que para extender la funcionalidad simplemente tendremos que modificar el DSL y no el comportamiento de ningún componente.
Una vez montado el proyecto deberemos arrancar mongodb y rabbitmq. Para ello en la carpeta
/docker/environment hay un docker-compose para arrancarlos en local.
También deberemos arrancar también el servidor de configuration. Podemos hacerlo también desde el docker-compose específico, arrancándolo desde nuestro IDE o utilizar el desplegado actualmente en AWS (en fase de desarrollo está aún como público para no tener que estar levantándolo cada dos por tres).
Después tenemos el proyecto insurance-bdd donde tenemos stories de diferentes operativas. Los test se encargan de arrancar
los diferentes módulos utilizados.
Se puede acceder a la consola de administración desde:
Las credenciales son las del usuario por defecto de la imagen docker: guest:guest.
En la comunicación entre los microservicios generalmente utilizaremos RabbitMQ para aquellas operativas que implican procesos de escritura (por ejemplo la generación de una orden), mientras que para las operaciones de escritura utilizaremos descubrimiento de servicios a través de Eureka (por ejemplo la consulta de la posición de una cartera).
-
Los módulos
${name}-corehacen referencia a proyectos de integración sin interface web. -
Los módulos
${name}-gatewayhacen referencia a los módulos web que generalmente explotan los servicios core utilizando AMQP y exponen una API REST.
El repositorio utilizado para la configuración es:
Temporalmente podremos utilizar la instancia desplegada en Amazón: