Data in Motion Tour 2022 - Madrid

1. Aplicando orientación a
eventos en cores de
Seguros
“When you start modeling events, it
forces you to think about the behaviour
of the system. As opposed to thinking
about the structure of the system.”
Greg Young

2. Andrés Hevia
Arquitecto T.I.
Developer Advocate
Arquitectura e Innovación
Área Corporativa de Tecnología
Email aheviav@mapfre.com
Twitter @a_hevia
Linkedin https://www.linkedin.com/in/hevia/
Aplicando orientación a eventos en cores de seguros

3. Equipo
287
215
136
206
645
251
MAPFRE RE+GR 44
MAPFRE ASISTENCIA 61
NORTAM
LAT-NOR
LAT-SUR
BRASIL
IBERIA
INFORMACIÓN ENERO 2022
TOTAL 1.844*
Equipo TI en el mundo
EURASIA

4. Declaración de
intenciones en EDA

5. Del modelo de peticiones al modelo de eventos
El caso del cambio de domicilio
Notificación de eventos:
• Desacoplamiento del receptor del emisor
• No hace falta tener conocimiento del comportamiento del sistema
Aplicando orientación a eventos en cores de seguros

6. Mejor push que pull
a.k.a: en lugar de ir a por ello, me lo mandas
• Cada microservicio tiene una copia de los datos que necesita para poder
ejecutarse 🡪 son autónomos
• El estado de una entidad de negocio (Customers) se transfiere a otro
microservicio mediante eventos
• Si el servicio de Customer se cae, el de Quoting puede seguir funcionando
• El servicio de Quoting tiene un subconjunto de los datos del cliente (los que
necesita para hacer la cotización)
• Los datos replicados implican Consistencia Eventual
Aplicando orientación a eventos en cores de seguros

7. 3 cosas a tener en cuenta:
Commands, Events y Queries
• Comandos:
• es una petición de una acción para que lo ejecute otro servicio
• Puede ejecutarse o no. Es una “esperanza de futuro”
• Se ejecutan síncronamente
• Es una llamada a un endpoint de un API
• Eventos:
• Es la notificación de un hecho: “viene del pasado”
• Algo que ha ocurrido en el mundo real y no tiene por qué
provocar ninguna acción
• Queries
• Es una petición para ver algo
• No tiene efecto en el sistema, permanece sin cambio alguno
Aplicando orientación a eventos en cores de seguros

8. La visión

9. Aplicando orientación a eventos en cores de seguros
... los eventos son el nuevo ORO
Hay procesos de negocio que se ejecutan una vez al
mes o incluso una vez al año por limitaciones
tecnológicas…
…debemos de ser capaces de reaccionar
en tiempo real a un evento significativo de
negocio en cualquier parte de la empresa
Si los datos son el nuevo petróleo…

10. Aplicando orientación a eventos en cores de seguros
Sistema “request – driven”

11. Aplicando orientación a eventos en cores de seguros
Sistema “event-driven”

12. ¿Qué estamos haciendo
con eventos en MAPFRE?

13. Aplicando orientación a eventos en cores de seguros
Dominio de Siniestros

14. Aplicando orientación a eventos en cores de seguros
Integración de Dominio de Siniestros con el Dominio de Visados

15. Dominio de Contratos
• Modelo de escritura consistente
• Actualizaciones constantes procedentes de terceras
aplicaciones
• No es necesario bloqueo lógico
Aplicando orientación a eventos en cores de seguros

16. Dominio de Contabilidad
• Contabilidad se basa en apuntes que se van a añadiendo en el sistema (append only)
• Capture all changes to an application state as a sequence of events (Martin Fowler)
• The truth is the log.
The database is a cache of a subset of the log.
That cached subset happens to be the latest value of each record and index value from
the log (Pat Helland)
Aplicando orientación a eventos en cores de seguros

17. Aplicando orientación a eventos en cores de seguros
Evolución de cores
• Evolución de cores sin rehacerlos
• Los nuevos módulos (cloud native) se
comunican con el core legacy mediante
eventos
• Máximo desacoplamiento
• Los eventos creados quedan a disposición
del resto de la empresa

18. Aplicando orientación a eventos en cores de seguros
Resumen
• Microservicios, mantenibles y escalables de forma independiente
• EDA (Event Driven Architecture)
• Los diferentes dominios (e incluso microservicios dentro de un mismo dominio, en el caso donde se considere) se
comunican mediante eventos
• CQRS (Command Query Responsibility Segregation)
• Se separa el modelo de escritura (Command) de los modelos de lectura (Query)
• Las escrituras son consistentes, asegurando que el estado N+1 siempre parte del estado N
• Las lecturas son eventualmente consistentes y actualizadas a través de eventos
• Event Sourcing
• Los eventos deben contener la entidad completa a la que se refieren, indicando además el porqué del cambio de
estado de la misma
• Tanto el modelo de escritura como los de lectura deben poder reconstruirse a partir de los eventos (event log)
• Un dominio sólo debe indicar en el evento aquellos datos de los que es propietario

19. y esto ¿Cómo
se gobierna?

20. Aplicando orientación a eventos en cores de seguros

21. Es una solución alineada con los
principios tecnológicos en
MAPFRE
• Cloud First
• SaaS mejor que PaaS mejor que IaaS
• Reducir la operación al mínimo posible
• Foco en open source, ampliado con soporte
empresarial
Y además…
son los inventores de Kafka ;-)
¿Por qué Confluent Cloud?