Biorąc pod uwagę usługę A (CMS), która kontroluje model (Produkt, załóżmy, że jedyne pola, które ma, to identyfikator, tytuł, cena) oraz usługi B (Wysyłka) i C (E-mail), które muszą wyświetlać dany model, jakie powinno być podejście zsynchronizować informacje o danym modelu w tych usługach w podejściu do pozyskiwania zdarzeń? Załóżmy, że katalog produktów rzadko się zmienia (ale się zmienia) i że istnieją administratorzy, którzy bardzo często uzyskują dostęp do danych przesyłek i wiadomości e-mail (przykładowe funkcje to: B: display titles of products the order containedi C display content of email about shipping that is going to be sent:). Każda z usług ma własną bazę danych.
Rozwiązanie 1
Wyślij wszystkie wymagane informacje o produkcie w ramach wydarzenia - oznacza to następującą strukturę dla order_placed:
{
order_id: [guid],
product: {
id: [guid],
title: 'Foo',
price: 1000
}
}
W serwisie B i C informacje o produkcie są przechowywane w productatrybucie JSON w orderstabeli
Jako taki, do wyświetlenia niezbędnych informacji wykorzystywane są tylko dane pobrane ze zdarzenia
Problemy : w zależności od tego, jakie inne informacje muszą być prezentowane w B i C, ilość danych w przypadku może wzrosnąć. B i C mogą nie wymagać tych samych informacji o Produkcie, ale wydarzenie będzie musiało zawierać oba (chyba że podzielimy zdarzenia na dwa). Jeśli podane dane nie są obecne w danym zdarzeniu, kod nie może ich użyć - jeśli dodamy opcję koloru do danego Produktu, dla istniejących zamówień w B i C, dany produkt będzie bezbarwny, chyba że zaktualizujemy zdarzenia, a następnie uruchomimy je ponownie .
Rozwiązanie 2
Wyślij tylko identyfikator produktu w ramach wydarzenia - oznacza to następującą strukturę dla order_placed:
{
order_id: [guid],
product_id: [guid]
}
W usługach B i C informacje o produkcie są przechowywane w product_idatrybucie w orderstabeli
Informacje o produkcie są pobierane przez usługi B i C, gdy jest to wymagane przez wykonanie wywołania interfejsu API do A/product/[guid]punktu końcowego
Problemy : powoduje to, że B i C zależą od A (przez cały czas). Jeśli schemat zmian produktu w A, należy wprowadzić zmiany we wszystkich usługach, które od nich zależą (nagle)
Rozwiązanie 3
Wyślij tylko identyfikator produktu w ramach zdarzenia - oznacza to następującą strukturę dla order_placed:
{
order_id: [guid],
product_id: [guid]
}
W usługach B i C informacje o produkcie są przechowywane w productstabeli; wciąż jest product_idna ordersstole, ale istnieje replikacja productsdanych między A, B i C; B i C mogą zawierać inne informacje o produkcie niż A
Informacje o produkcie są inicjowane podczas tworzenia usług B i C i są aktualizowane za każdym razem, gdy informacje o Produktach ulegają zmianie przez wywołanie A/productpunktu końcowego (który wyświetla wymagane informacje o wszystkich produktach) lub przez bezpośredni dostęp DB do A i skopiowanie niezbędnych informacji o produkcie wymaganych dla danego produktu usługa.
Problemy : powoduje to, że B i C zależą od A (podczas wysiewu). Jeśli schemat zmian produktu w A, należy wprowadzić zmiany we wszystkich usługach, które od nich zależą (podczas inicjowania)
Z mojego zrozumienia, poprawnym podejściem byłoby iść z rozwiązaniem 1 i albo aktualizować historię zdarzeń zgodnie z pewną logiką (jeśli katalog produktów nie zmienił się i chcemy dodać wyświetlany kolor, możemy bezpiecznie zaktualizować historię, aby uzyskać aktualny stan Produktów i uzupełnij brakujące dane w ramach wydarzeń) lub uwzględnij nieistnienie danych (jeśli zmienił się katalog Produktów i chcemy dodać kolor do wyświetlenia, nie możemy być pewni, czy w danym momencie dany Produkt był w przeszłości miał kolor, czy nie - możemy założyć, że wszystkie Produkty z poprzedniego katalogu były czarne i uwzględniono je poprzez aktualizację zdarzeń lub kodu)
updating event historyNie mam na myśli: przejrzyj wszystkie zdarzenia, kopiując je z jednego strumienia (v1) do innego strumienia (v2), aby zachować spójny schemat zdarzeń.
display image at the point when purchase was made) lub nie może (reprezentować zamiar display current image as it within catalog)
updating event history- W przypadku pozyskiwania zdarzeń historia zdarzeń jest Twoim źródłem prawdy i nigdy nie powinna być zmieniana, a jedynie iść do przodu. Jeśli zdarzenia się zmienią, możesz użyć wersji zdarzeń lub podobnych rozwiązań, ale podczas odtwarzania zdarzeń do określonego momentu stan danych powinien być taki, jak w tym momencie.