Dato il servizio A (CMS) che controlla un modello (Prodotto, supponiamo che gli unici campi che ha sono ID, titolo, prezzo) e i servizi B (Spedizione) e C (Email) che devono visualizzare un determinato modello quale dovrebbe essere l'approccio sincronizzare le informazioni del modello dato attraverso quei servizi nell'approccio di approvvigionamento di eventi? Supponiamo che il catalogo dei prodotti cambi raramente (ma cambi) e che ci siano amministratori che possono accedere ai dati di spedizioni ed e-mail molto spesso (le funzionalità di esempio sono: B: display titles of products the order contained
e C:) display content of email about shipping that is going to be sent
. Ognuno dei servizi ha il proprio DB.
Soluzione 1
Invia tutte le informazioni richieste sul Prodotto all'interno dell'evento - ciò significa la seguente struttura per order_placed
:
{
order_id: [guid],
product: {
id: [guid],
title: 'Foo',
price: 1000
}
}
Le informazioni sul prodotto B e C del servizio sono archiviate nell'attributo product
JSON nella orders
tabella
Pertanto, per visualizzare le informazioni necessarie vengono utilizzati solo i dati recuperati dall'evento
Problemi : a seconda di quali altre informazioni devono essere presentate in B e C, la quantità di dati nell'evento può aumentare. B e C potrebbero non richiedere le stesse informazioni sul Prodotto, ma l'evento dovrà contenere entrambi (a meno che non separiamo gli eventi in due). Se determinati dati non sono presenti all'interno di un determinato evento, il codice non può utilizzarli - se aggiungeremo un'opzione di colore a un determinato Prodotto, per gli ordini esistenti in B e C, un determinato prodotto sarà incolore a meno che non aggiorniamo gli eventi e quindi li eseguiamo nuovamente .
Soluzione 2
Invia solo guida del prodotto all'interno dell'evento - ciò significa la seguente struttura per order_placed
:
{
order_id: [guid],
product_id: [guid]
}
Sui servizi le informazioni sui prodotti B e C sono memorizzate product_id
nell'attributo nella orders
tabella
Le informazioni sul prodotto vengono recuperate dai servizi B e C quando richiesto eseguendo una chiamata API A/product/[guid]
all'endpoint
Problemi : questo rende B e C dipendenti da A (in ogni momento). Se lo schema del Prodotto cambia su A, le modifiche devono essere fatte su tutti i servizi che dipendono da loro (improvvisamente)
Soluzione 3
Invia solo una guida al prodotto all'interno dell'evento - questo significa la seguente struttura per order_placed:
{
order_id: [guid],
product_id: [guid]
}
Sui servizi B e C le informazioni sul prodotto sono memorizzate nella products
tabella; c'è ancora product_id
sul orders
tavolo, ma c'è la replica dei products
dati tra A, B e C; B e C potrebbero contenere informazioni diverse sul Prodotto rispetto ad A
Le informazioni sul prodotto vengono trasmesse quando vengono creati i servizi B e C e vengono aggiornati ogni volta che le informazioni sui prodotti cambiano effettuando una chiamata A/product
all'endpoint (che visualizza le informazioni richieste su tutti i prodotti) o eseguendo un accesso diretto al database A e copiando le informazioni necessarie sul prodotto richieste servizio.
Problemi : questo rende B e C dipendenti da A (durante la semina). Se lo schema del Prodotto cambia su A, le modifiche devono essere fatte su tutti i servizi che dipendono da loro (durante il seeding)
Secondo la mia comprensione, l'approccio corretto sarebbe quello di andare con la soluzione 1 e aggiornare la cronologia degli eventi secondo una certa logica (se il catalogo dei prodotti non è cambiato e vogliamo aggiungere il colore da visualizzare, possiamo aggiornare la cronologia in modo sicuro per ottenere lo stato corrente dei prodotti e riempire i dati mancanti all'interno degli eventi) o provvedere alla non esistenza di dati dati (se il catalogo dei prodotti è cambiato e vogliamo aggiungere il colore da visualizzare, non possiamo essere sicuri se a quel punto nel passato in quel dato prodotto aveva un colore o no - possiamo presumere che tutti i prodotti nel catalogo precedente fossero neri e approvati aggiornando eventi o codice)
updating event history
intendo: esaminare tutti gli eventi, copiandoli da uno stream (v1) a un altro stream (v2) per mantenere uno schema di eventi coerente.
display image at the point when purchase was made
) o no (che rappresenta l'intento di display current image as it within catalog
)
updating event history
- In caso di approvvigionamento, la cronologia degli eventi è la tua fonte di verità e non dovrebbe mai essere modificata, ma solo andare avanti. Se gli eventi cambiano, è possibile utilizzare il versioning degli eventi o soluzioni simili, ma quando si riproducono gli eventi fino a un determinato momento, lo stato dei dati dovrebbe essere come era a quel punto.