Jak zarządzać zmianami modelu widoku w architekturze CQRS + Event Sourcing

Question

Jak zarządzać zmianami modelu widoku w architekturze CQRS + Event Sourcing

Obecnie oceniamy architektury CQRS i Event Sourcing. Staram się zrozumieć, jakie są konsekwencje konserwacji wynikające z używania tego rodzaju konstrukcji. Dwa pytania, na które trudno mi znaleźć odpowiedzi to:

1) Co się stanie, jeśli po uruchomieniu aplikacji przez jakiś czas pojawi się nowy wymóg dodania dodatkowego pola do modelu widoku w bazie danych ReadModel? Powiedzmy, że Kod Pocztowy klienta jest wymagany na Customerlist ViewModel, gdzie był nie wcześniej. Tak więc dodatkowa kolumna może być łatwo dodana do bazy danych ViewModel, ale w jaki sposób zostanie ona wypełniona? Z tego, co widzę, jedynym sposobem jest wyczyszczenie bazy danych read i odtworzenie wszystkich zdarzeń od zera, aby utworzyć kopię zapasową bazy danych ReadModel. Ale co, jeśli aplikacja działa od miesięcy lub lat(jak mamy nadzieję). To mogą być miliony zdarzeń do odtworzenia, tylko po to, aby dodać dane dla kolumny zipcode.

Mam to samo zmartwienie, Jeśli, za cokolwiek powód techniczny, Baza Danych modeli ReadModel została zsynchronizowana lub chcemy dodać nową bazę danych modeli ReadModel. Wydaje się, że im starsza jest aplikacja, a im więcej jest używana, tym trudniej i drożej jest uzyskać z powrotem aktualną wersję readmodel. Czy gdzieś przegapiłem jakąś sztuczkę? Coś w stylu ReadModel snapshots?

2) Co się stanie, jeśli po odtworzeniu wszystkich milionów zdarzeń w celu utworzenia kopii zapasowej odczytywanej bazy danych, niektóre dane nie pasują do tego, czego oczekiwano (tj. wygląda źle). Uważa się, że być może przyczyną tego był błąd gdzieś w przechowywaniu zdarzeń lub procedurach denormalizacji (i wydaje się, że jeśli jest jedna rzecz, na której możesz polegać w kodowaniu, to są to błędy). Jak przejść do debugowania tego! To wydaje się niemożliwe. A może znowu coś mi umyka.

Chciałbym usłyszeć od każdego, kto od jakiegoś czasu prowadzi taki system, jak przebiegały ścieżki konserwacji i aktualizacji dla ty.

Dzięki za każdy czas i wkład.

18

design-patterns architecture cqrs event-sourcing

Author: James, 2011-04-07

Source

4 answers

Jestem trochę nowy w CQRS, więc może to nie jest najbardziej wskazane (ale IIRC wybrałem go z jednej z list dyskusyjnych CQRS/DDDD).

Tworzymy polecenie i odpowiednią obsługę specyficzną dla celu, który ma być uruchomiony raz, a następnie przestarzały.

W handlerze używamy dowolnego mechanizmu, który jest wygodny, więc w przypadku dodania pola z kodem pocztowym możemy uruchomić jednorazowe zapytanie, które ściągnie kody pocztowe w tym momencie z innego modelu widoku i zapełni nowy kolumna. Nie martwimy się zbytnio o czystość architektury w tych scenariuszach, ponieważ oczekuje się, że będzie to operacja Jednorazowa (masywnyRoba Conery ' ego został użyty z powodzeniem w tych sytuacjach).

1

Author: quentin-starin,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-04-07 19:18:26

Nie mam jeszcze gotowej do produkcji aplikacji wykorzystującej cqrs z event sourcing, więc oto moje doświadczenie, próbując ją zbudować.

1) Read Model rebuild. Tak, w zasadzie trzeba odbudować cały odczyt modelu DB, gdy coś w nim się zmieni. A jeśli jest wiele wydarzeń, może to zająć dużo czasu. Tak więc przebudowa modelu odczytu musi być wysoce zoptymalizowana (użyj wsadowania zdarzeń, itp.). Uważam, że event sourcing pasuje najlepiej w przypadkach, gdy istnieje wysoki współczynnik odczytu i zapisu. Więc dla niektórych bardzo niestabilnych danych, może bądź mądry, aby nie przechowywać go jako zdarzenia domeny. Ale pytanie o pojemność pamięci jest również nie tak daleko. W każdym razie możesz zastosować CQR tylko do części systemu, tej, w której pasuje najlepiej (np. prawdopodobnie nie przechowywałbym graficznego obrazu jako części zdarzenia).

2) Debugging. Jest wysoce nieprawdopodobne, aby wystąpił błąd w przechowywaniu zdarzeń (powinno to być problemem frameworka) i zawsze łatwo jest sprawdzić, jakie zdarzenia są w sklepie. Co do komend do produkcji oczekiwanych events, powinieneś mieć tutaj testy, a te testy będą prawdopodobnie najcenniejszymi testami w systemie. W przypadku denormalizerów można też mieć testy, ale nie zawracałbym sobie głowy pisaniem testów na trywialne denormalizery, gdyby ich rdzeń można było zobaczyć gołym okiem. Mając to na uwadze, użyłem debuggera kilka razy, aby znaleźć problemy w bardziej skomplikowanych denormalizerach; nie było to zbyt zabawne, próbując określić, które zdarzenie powoduje, że wszystko idzie źle.

1

Author: driushkin,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-04-07 20:03:09

Możliwe jest również dodanie zdarzenia siatki w modelu. To może być uruchomione jako dowolne zadanie po otrzymaniu X liczby zdarzeń (powiedzmy 500)

Aby odbudować, wciskasz swoje zdarzenia na stos, aż trafisz w Zdarzenie siatki, które jest używane jako linia bazowa, stąd wyrzucasz zdarzenia ze stosu, agregując ich wartości z wydarzeniem linii bazowej.

0

Author: Slappy,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-04-14 23:26:32

score 16 · Accepted Answer

Piękno korzystania z event sourcingu za pomocą CQRS jest możliwość zniszczenia modelu read i odbudowania go od podstaw, jak już wspomniano. Z jakiegoś powodu ludzie mają ten pomysł, że to zajmie dużo czasu po tym, jak pojawi się powyżej dowolnej liczby zdarzeń. Jeśli używasz relacyjnej bazy danych dla swoich Modeli odczytu-i najprawdopodobniej tak jest - łatwo jest otworzyć transakcję, odczytać wszystkie zdarzenia za pomocą programów obsługi, a następnie zatwierdzić transakcję. Tylko wtedy, gdy transakcja potwierdza, że rzeczywiście dotykamy dysku. Wszystko inne jest wykonywane w pamięci, więc może być błyskawicznie. Nie zdziwiłbym się, gdyby Twój system przeszedł kilka milionów zdarzeń w ciągu kilku minut.

Przebudowa odczytywanych modeli od podstaw powinna wyświetlać się dokładnie tak samo, jak codzienna metoda denormalizacji zdarzeń w odczytanych modelach. Jeśli nie, masz błąd w kodzie denormalizacji modelu odczytu. Najwspanialsze jest to, że z punktu widzenia obsługi wiadomości nie ma różnicy między odbieranym zdarzeniem a denormalizowanym w modelu odczytywanym podczas scenariuszy regularnych/produkcyjnych a scenariuszami read-model rebuild.

Jeśli napotkasz błędy, możesz łatwo debugować, przesyłając strumieniowo / kopiując zdarzenia produkcyjne do lokalnej stacji roboczej, ustawiając punkty przerwania w programach obsługi, a następnie uruchamiając te zdarzenia za pomocą kodu obsługi odczytu modelu.