Dado el servicio A (CMS) que controla un modelo (producto, supongamos que los únicos campos que tiene son id, título, precio) y los servicios B (envío) y C (correos electrónicos) que tienen que mostrar el modelo dado cuál debería ser el enfoque. sincronizar la información del modelo dado en esos servicios en el enfoque de abastecimiento de eventos? Supongamos que el catálogo de productos rara vez cambia (pero cambia) y que hay administradores que pueden acceder a los datos de envíos y correos electrónicos con mucha frecuencia (las funcionalidades de ejemplo son: B: display titles of products the order contained
y C:) display content of email about shipping that is going to be sent
. Cada uno de los servicios tiene su propia base de datos.
Solución 1
Enviar toda la información requerida sobre el Producto dentro del evento; esto significa la siguiente estructura para order_placed
:
{
order_id: [guid],
product: {
id: [guid],
title: 'Foo',
price: 1000
}
}
En el servicio B y C, la información del producto se almacena en el product
atributo JSON en la orders
tabla
Como tal, para mostrar la información necesaria solo se utilizan los datos recuperados del evento
Problemas : dependiendo de qué otra información se deba presentar en B y C, la cantidad de datos en el evento puede crecer. B y C pueden no requerir la misma información sobre el Producto, pero el evento tendrá que contener ambos (a menos que separemos los eventos en dos). Si los datos dados no están presentes dentro del evento dado, el código no puede usarlo; si agregaremos una opción de color al Producto dado, para los pedidos existentes en B y C, el producto dado será incoloro a menos que actualicemos los eventos y luego los volvamos a ejecutar .
Solución 2
Enviar solo el guid del producto dentro del evento; esto significa la siguiente estructura para order_placed
:
{
order_id: [guid],
product_id: [guid]
}
En los servicios B y C, la información del producto se almacena en el product_id
atributo de la orders
tabla
La información del producto es recuperada por los servicios B y C cuando es necesario al realizar una llamada API al A/product/[guid]
punto final
Problemas : esto hace que B y C dependan de A (en todo momento). Si el esquema del Producto cambia en A, los cambios deben hacerse en todos los servicios que dependen de ellos (de repente)
Solución 3
Enviar solo el guid del producto dentro del evento; esto significa la siguiente estructura para order_placed:
{
order_id: [guid],
product_id: [guid]
}
En los servicios B y C, la información del producto se almacena en la products
tabla; todavía hay product_id
en la orders
mesa, pero hay replicación de products
datos entre A, B y C; B y C pueden contener información diferente sobre el Producto que A
La información del producto se siembra cuando se crean los servicios B y C y se actualizan cada vez que la información sobre los Productos cambia haciendo una llamada al A/product
punto final (que muestra la información requerida de todos los productos) o realizando un acceso directo de base de datos a A y copiando la información necesaria del producto requerida para Servicio.
Problemas : esto hace que B y C dependan de A (cuando se siembra). Si el esquema de Producto cambia en A, los cambios deben hacerse en todos los servicios que dependen de ellos (cuando se inicia)
Según tengo entendido, el enfoque correcto sería ir con la solución 1, y actualizar el historial de eventos según cierta lógica (si el catálogo del Producto no ha cambiado y queremos agregar color para mostrar, podemos actualizar el historial de forma segura para obtener el estado actual de productos y rellenar datos faltantes dentro de los eventos) o atender la inexistencia de datos dados (si el catálogo de productos ha cambiado y queremos agregar el color que se mostrará, no podemos estar seguros si en ese momento en el pasado producto dado tenía un color o no, podemos suponer que todos los productos en el catálogo anterior eran negros y se atienden al actualizar eventos o código)
updating event history
quiero decir: revisa todos los eventos, copiándolos de un flujo (v1) a otro flujo (v2) para mantener un esquema de eventos consistente.
display image at the point when purchase was made
) o no puede (representa la intención de display current image as it within catalog
)
updating event history
: en el evento de abastecimiento, el historial de eventos es su fuente de verdad y nunca debe modificarse, sino que solo debe avanzar. Si los eventos cambian, puede usar versiones de eventos o soluciones similares, pero al reproducir sus eventos hasta un punto específico en el tiempo, el estado de los datos debe ser como era en ese punto.