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

https://github.com/labcabrera/lab-insurance/wiki