Ahora mismo no se están controlando los errores de ningún modo. Si algo peta peta. Si un mensaje encola no se procesa bien en muchos casos intentará re-ejecutarse hasta el infinito

Revisar si hay alguna aproximación ya desarrollada al sistema que existe con JPA:

https://docs.spring.io/spring-data/data-jpa/docs/1.7.0.DATAJPA-580-SNAPSHOT/reference/html/auditing.html

El modelo actual es una versión cero que simplemente tiene un String para identificar el estado de las entidades y una información de auditoría básica.

Unificar el sistema para tener un modelo común y poder gestionar las acciones, transiciones y los estados de forma más sencilla.

Por ejemplo ahora la configuración para el gateway de activos es:

/api/assets/**

Y el el módulo tenemos por ejemplo mapeado:

assets/isin/{isin}

De modo que la url tiene el elemento assets duplicado:

http://localhost:8080/api/assets/assets/isin/ASSET01

En cambio no quiero mapear directamente /isin/{isin} dado que en / tendremos otros recursos.

Se puede cambiar a /search/ aunque no encaja mucho con las convenciones de nombres

Acordar un sistema de carga inicial de sistema con la parametrización básica

Ahora mismo mongo se arranca con un script de la carpeta resources a modo de poc.

Estudiar si cada módulo core debería ser responsable de auto-popularse cuando arranca (pensar si las funcionalidades de spring-batch son las más adecuadas)

Básicamente hacer la integración de un modo similar a:

https://github.com/labcabrera/lab-oauth2

Hay que ver si las últimas versiones implementan el acceso a los tokens via mongo (si que lo tienen para jdbc) o de si hay que desarrollarlo.

Actualmente el módulo insurance-domain tiene el modelo de todos los módulos.

Hay que separarlo para que cada módulo contenga las entidades propias y que el modelo común sólo contega los contratos de alto nivel entre los diferentes módulos para simplificar la comunicación entre ellos.

El primer candidato es el módulo portfolio. Este sólo debería exponer información tal como la información de la provisión matemática de una cartera y no la información interna con la que se va a persistir.

Revisar por que no funciona lo que en la documentación debería funcionar

Se supone que registando la ruta con el nombre del recurso que se registra en eureka podemos mapear:

zuul:
prefix: /api
routes:
${nombre-de-mi-modulo}: /{path}**

Pero eso no funciona así que tengo que tener los mapeos que sólo funcionan en local:

zuul:
prefix: /api
routes:
insurance-contract-common-gateway:
path: /contracts/**
url: http://localhost:8090/

Añadir servidor de OAuth2 e integrar la seguridad basada en tokens JWT

Estructura inicial de comisiones y gastos mensuales

Arreglar la compilación en travis y perfilizar aquellas pruebas que son unitarias y aquellas que son de integración.

Durante el proceso de valorización de una orden (OrderValorizationDslConfig) se necesita leer los precios de los assets involucrados.

Mi primera idea es hacerlo vía amqp utilizando un splitter-aggretator, de tal modo que espero hasta que recibo el mensaje con los precios para seguir con la operación

Otra opción sería hacerlo vía REST con el asset-gateway

Me gusta más la primera opción aunque también resulta bastante más complicada y no sé si tiene alguna ventaja que lo compense (aparte de que los test no dependerían de tener levantado el servicio)

Mejorar la definición en gradle de los proyectos

Actualmente la resolución de dependencias está basada en este clunky-workaround:

configure(subprojects.findAll {it.name.endsWith("-core")}) { ... }

configure(subprojects.findAll {it.name.endsWith("-gateway")}) { ... }

El sistema más básico es buscar a partir de determinados criterios (mirar si ya tiene un id, comprobar por número de identificación, etc) si ya existe. En en el caso de no existir simplemente se registra cuando se persiste el contrato.

Extraer la lógica al módulo de entidades legales y definir una parametrización que no esté acoplada al modelo de contratación (por ejemplo para una app solamente vamos a requerir el email, mientras que en otra deberemos verificar la información proporcionada antes de proceder a la validación del contrato)

Esto implica:

• Definición de las APIs REST de los diferentes gateways
• Integración de zuul
• Determinar los tipos de frontales que va a tener la aplicación

Abstracción del modelo de contratación

Hacer independiente del sistema de los flujos (por ejemplo sería equivalente la contratación de un seguro que abrir una cuenta en una web-app para operar en bolsa a tiempo real)

Generar las rutas DSL en función del tipo de órden

Generación de los market-orders

Ahora el modelo de entidades es bastante pobre y diferencia entre personas físicas y jurídicas.

Separar el modelo a un módulo aparte del que dependa insurance-domain y completarlo.

Extraer la configuración de los módulos para que todos ataquen contra el cloud (a excepción del bdd)

Ahora mismo no se proporciona ninguna utilidad que facilite la configuración entre los módulos

Sería interesante tener una configuración común para los módulos core y gateway que extraiga el factor común y simplifique la configuración vía org.springframework.context.annotation.ImportSelector & cia.

Lo prioritaría sería:

• mongo
• rabbit
• eureka
• zuul

En la simulación de ejecución de acciones la asincronía es un problema dado que no se controla que se incremente el día a procesar sólo cuando las acciones han terminado

En un entorno productivo esto no debería pasar dado que el margen de tiempo para que se procesen las acciones es suficiente, pero cuando se ejecuta a lo bestia no da tiempo.

Hay algo montado en la máquina de ejecución de acciones para funcionar de modo síncrono, pero falta por darle una vuelta o dos.

Pienso que unar un sheduler convencional no es suficiente para solucionar las probleméticas de la aplicación (básicamente definir ciertas acciones que deben ser ejecutadas a una fecha dada con cierta orquestación adicional en funcion de aspectos programáticos)

La solucion que tengo en la cabeza es añadir un modelo específico de acciones que deben ser ejecutadas y montar el scheduler/polling sobre el: ir persistiendo en cada módulo las acciones que se deben ejecutar en cada determinado momento y un sistema sencillo que se encargue de irlas encolando a partir de la información de cada ejecución

Estudiar alternativas menos home-made

Básicamente:

• insurance-services
• insurance-bootstrap
• insurance-engine

He tenido que comentar varios test por problemas con uso de api eliminada de spring.

Revisar con más calma, no me gustaría tener que quitar DSL y usar integration a pelo.

Ahora mismo las colas de amqp están hardcodeadas. La idea es que sean parametrizables de modo que en el proceso de adaptación (framework -> producto) puedan simplemente cambiarse para extender funcionalidades particulares

Ahora los docker-compose están montados para el entorno de desarrollo local.

Estaría bien ir montando cada una de las imágenes de los módulos para poder publicarlas sin teclear demasiado en AWS o donde sea