Skip to content

labcabrera/lab-insurance

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Open Asset Management System (beta)

Build Status Codacy code quality

Introducción

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

lab-insurance-asset

Microservicios de gestión de activos.

lab-insurance-asset-api
lab-insurance-asset-core

lab-insurance-portfolio

Microservicios de gestión de carteras.

lab-insurance-portfolio-api
lab-insurance-portfolio-core

lab-insurance-legal-entity

Microservicios de gestión de entidades legales.

lab-insurance-financial-services

Microservicios de servicios financieros.

lab-insurance-order

Microservicios de gestión de órdenes.

lab-insurance-broker

Microservicios de integración con brokers.

lab-insurance-contract

Microservicios de contratación.

lab-insurance-agreement

Microservicios de acuerdos marco.

lab-insurance-fees

Microservicios de gastos y comisiones.

lab-insurance-scheduler

Programador de tareas.

lab-insurance-zuul

Proxy.

lab-insurance-bdd

Pruebas de integración

n/a

lab-insurance-cloud-config-server

Servidor de configuración.

lab-insurance-cloud-config-server

lab-insurance-ng

Frontend.

lab-insurance-eureka

Eureka.

labcabrera/lab-insurance-eureka

lab-insurance-cloud-config

Repositorio de configuración.

n/a

lab-insurance-sso

Servidor de autenticación.

Domain model

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.

Contratación

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 ContractCreationData que 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.

Development

Ejecutando el proyecto

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.

RabbitMQ

Se puede acceder a la consola de administración desde:

Las credenciales son las del usuario por defecto de la imagen docker: guest:guest.

RabbitMQ vs Eureka

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).

Nomenclatura de los módulos:

  • Los módulos ${name}-core hacen referencia a proyectos de integración sin interface web.

  • Los módulos ${name}-gateway hacen referencia a los módulos web que generalmente explotan los servicios core utilizando AMQP y exponen una API REST.

Git cloud config

El repositorio utilizado para la configuración es:

Temporalmente podremos utilizar la instancia desplegada en Amazón:

References