Biorąc pod uwagę, że masz wiele systemów, które są zintegrowane przez zdarzenia, a wszystkie z nich korzystają ze źródeł zdarzeń. Gdzie przechowujesz wydarzenia?

W moim przypadku mam trzy systemy:

  • Strona internetowa, która jest sklepem
  • Backend dla Serwisu do zarządzania klientami, produktami itp.
  • System księgowy

Za każdym razem, gdy zdarzenie domeny ma miejsce w jednym z tych systemów, zdarzenie jest publikowane i może być przetwarzane przez inne systemy. Wszystkie systemy korzystają ze źródeł zdarzeń.

Zastanawiam się, gdzie zapisałbyś wydarzenia. Oczywiście każdy system musi przechowywać wszystkie przetworzone zdarzenia, ponieważ korzysta ze źródła zdarzeń i w związku z tym zależy od zdarzeń, które zostały przetworzone.

Ale co z innymi wydarzeniami, które nie były potrzebne i dlatego system nie zapisał się? Borykam się z faktem, że wymagania mogą się zmienić tak, że system musiałby przetworzyć zdarzenia z przeszłości, żeby się nie utrzymywały. Skąd wziąłbyś te zdarzenia, jeśli system musiałby przetwarzać zdarzenia, których nie subskrybował, gdy się pojawiły?

Myślę, że jest duża różnica w porównaniu z systemami, które w tym momencie nie korzystają ze źródeł zdarzeń. Jeśli musisz zaimplementować funkcję w systemie A, która zależy od danych, które nie są dostępne w A, ale w innym systemie B, i utrzymujesz bieżący stan za pomocą narzędzia ORM, takiego jak NHibernate, możesz po prostu zaimportować te dane z A do B Ponieważ system, który używa źródła zdarzeń, zależy od zdarzeń, aby dostać się do swojego aktualnego stanu, musisz zaimportować wszystkie zdarzenia, które przegapiłeś w przeszłości, ale są potrzebne teraz.

Dla mnie istnieje kilka różnych podejść do tego problemu.

  1. Każdy system zapisuje wszystkie publikowane zdarzenia. Daje to możliwość ponownego opublikowania zdarzeń w razie potrzeby lub zaimportowania ich do innego systemu.
  2. Każdy system zapisuje wszystkie zdarzenia, które mają miejsce, nawet te, które (jeszcze) nie muszą być przetwarzane.
  3. Wszystkie zdarzenia z całego systemu są przechowywane w centralnym dzienniku zdarzeń. Jeśli chcesz przetworzyć wydarzenie, które miało miejsce w przeszłości, ale nie subskrybowałeś, możesz je zaimportować stąd.

Jak radzisz sobie w takiej sytuacji? Gdzie zapisujesz swoje wydarzenia?

Edytuj

Dziękuję Royowi Dictusowi za odpowiedź. Nadal nie jestem pewien, jak poradzić sobie z następującą sytuacją:

Na stronie publikowane są zdarzenia CustomerRegistered, CustomerPurchasedProduct oraz CustomerMarkedProductAsFavorite. W obecnej wersji backendu klienci muszą być wyświetlani, a ich zakupy muszą być widoczne. To, co klient oznaczył jako ulubione, nie jest zainteresowane tą wersją systemu. W ten sposób backend subskrybował tylko CustomerRegistered i CustomerPurchasedProduct.

Teraz dział marketingu chce również, aby informacje o ulubionych produktach były wyświetlane na stronie z danymi klienta. Ponieważ backend nie zasubskrybował CustomerMarkedProductAsFavorite, ta informacja nie jest dostępna w backendzie. Skąd czerpię te informacje?

7
Alebo 4 czerwiec 2011, 22:42

2 odpowiedzi

Najlepsza odpowiedź
  1. Każdy system przechowuje własne zdarzenia. Każdy system jest własnym systemem CQRS, a przynajmniej własną, samodzielną usługą, a zatem odpowiada za własne dane.
  2. Każdy system publikuje również swoje zdarzenie w magistrali usług. Ta magistrala usług określa, gdzie zapisuje te zdarzenia. Zwykle jest to transakcyjny system kolejkowy.
  3. Każdy system subskrybuje zdarzenia zewnętrzne, które wykorzystuje. Nie przechowuje tych nadchodzących zdarzeń, tylko własne zdarzenia, które z nich wynikają. Gdy zużywa zdarzenie przychodzące, usługa Service Bus wie, że może usunąć zdarzenie z kolejki przychodzącej tej usługi.

EDYTUJ, aby uwzględnić dodatkowe pytanie:

Jeśli inna aplikacja nagle zainteresuje się dodatkowymi informacjami, musi dodać słuchaczy do wydarzeń, którymi jest teraz zainteresowana.

Co więcej, wszystkie źródła tych wydarzeń mogą następnie je odtworzyć. Powtórka to potężna funkcja systemów sterowanych zdarzeniami, która pozwala na takie scenariusze. Tak więc źródła zdarzeń odtwarzają tylko wybrane zdarzenia (powiedzmy, wszystkie zdarzenia CustomerMarkedItemAsFavorite z ostatnich 6 miesięcy). Systemy, które już wykorzystały te zdarzenia, powinny rozpoznać, że odtwarzane zdarzenia są „stare” (tj. takie, które już przetworzyły) i zignorować je.

W ten sposób każdy podsystem, który jest aktualizowany w celu wykorzystania dodatkowych informacji z innych podsystemów, może uzyskać te informacje i zaktualizować je w ramach jednej operacji wsadowej.

7
Roy Dictus 5 czerwiec 2011, 18:16
Dziękuję. Proszę zobaczyć moją edycję poniżej. Dodałem scenariusz, z którym jeszcze nie wiem jak sobie poradzić.
 – 
Alebo
5 czerwiec 2011, 12:57

WRT twoja edycja: czy naprawdę wymagany jest dostęp do historycznych danych CustomerMarkedProductAsFavorite. Zmień backend, aby zasubskrybować nowe dane, a następnie masz to do przodu. Możesz dowiedzieć się, jak uzupełnić brakujące dane jako osobny problem, jeśli naprawdę tego potrzebujesz.

Roy nakreślił już jedną możliwą architekturę, która zapewni, że w przyszłości będziesz mieć dane o produkcie oznaczonym przez klienta jako ulubiony.

0
Jim Hooker 5 czerwiec 2011, 13:14
Po prostu wymyśliłem ten przykład. Myślę jednak, że byłby to wymóg dostępu do danych historycznych, ponieważ ktokolwiek spojrzałby na ulubione w backendzie, spodziewałby się, że są one kompletne.
 – 
Alebo
5 czerwiec 2011, 13:44