Usługi, które są odpowiedzialne za monitorowanie bilansu i wykonywanie pewnych działań, gdy spada poniżej zera.
Streszczenie: sposób, w jaki jest to obsługiwane w systemach pochodzących z wydarzeń, nie różni się tak bardzo od rozwiązań alternatywnych.
Odsunięcie drugie - zaletą posiadania modelu domeny jest zapewnienie, że wszystkie proponowane zmiany spełniają reguły biznesowe. Pożyczanie z języka CQRS: wysyłamy komunikaty poleceń do programu obsługi poleceń. Procedura obsługi ładuje stan modelu i próbuje zastosować polecenie. Jeśli polecenie jest dozwolone, zmiany stanu modelu domeny są aktualizowane i zapisywane.
Po utrzymaniu stanu modelu, moduł obsługi komend może wysłać zapytanie do tego stanu, aby ustalić, czy są to zaległe akcje, które należy wykonać. Udi Dahan opisuje to szczegółowo w swoim wykładzie na temat Reliable messaging.
Najbardziej prostym sposobem opisywania usługi jest aktualizacja modelu za każdym razem, gdy zmienia się bilans konta, i ustawienie flagi "przekroczony limit", jeśli saldo jest ujemne. Po zapisaniu modelu planujemy wszelkie działania związane z tym stanem.
Część uzasadnienia dla pozyskiwania zdarzeń polega na tym, że stan modelu domeny można uzyskać z historii. Co oznacza, że kiedy próbujemy ustalić, czy model pozwala na polecenie, wczytujemy historię i obliczamy z historii bieżący stan, a następnie używamy tego stanu, aby określić, czy polecenie jest dozwolone.
W praktyce oznacza to, że możemy napisać zdarzenie AccountOver Drawn w tym samym czasie, w którym zapisujemy zdarzenie AccountDebited.
Zdarzenie AccountDebited można subskrybować - Pub/Sub. Typowe postępowanie polega na tym, że nowe wydarzenia są publikowane po ich pomyślnym zapisaniu w księdze rekordów. Detektor zdarzeń subskrybujących zdarzenia wychodzące z modelu domeny obserwuje zdarzenie i planuje uruchomienie polecenia.
Dygresja: zazwyczaj będziemy potrzebować co najmniej jednokrotnego wykonania tych czynności. Oznacza to śledzenie potwierdzeń.
W związku z tym obsługa zdarzeń jest również rzeczą o stanie.Nie ma w nim żadnego stanu, a na pewno nie ma reguł, które pozwoliłyby mu odrzucać zdarzenia. To, co śledzi, to, które zdarzenia widział i jakie działania należy zaplanować. Reguły ładowania tego modułu obsługi zdarzeń (zwane częściej menedżerem procesów) są podobne do tych w modelu domeny - ładuj zdarzenia z księgi rekordów, aby uzyskać bieżący stan, a następnie sprawdź, czy obsługiwane wydarzenie zmienia cokolwiek.
To naprawdę subskrybuje dwa zdarzenia - zdarzenie AccountDebited i każde zdarzenie, które powraca z działania, aby potwierdzić, że zostało zakończone.
Ta sama mechanika może być użyta do aktualizacji modelu domeny w odpowiedzi na zdarzenia z innych źródeł.
Przykład: załóżmy, że otrzymujemy zdarzenie FundsWithdrawn z bankomatu i musimy zaktualizować historię konta, aby do niego pasować. W związku z tym nasz moduł obsługi zdarzeń jest ładowany, aktualizuje się i planuje uruchomienie polecenia RecordATMWithdrawal. Po załadowaniu polecenia ładuje konto, aktualizuje salda i zapisuje zdarzenia AccountCredited i AccountOverdrawn, jak wcześniej. Program obsługi zdarzeń widzi te zdarzenia, ładuje prawidłowy stan procesu stanu na podstawie danych meta i aktualizuje stan procesu.
W terminach CQRS wszystko to ma miejsce w "modelach zapisu"; procesy te polegają na aktualizacji księgi rekordów.
Samo zapytanie o saldo jest łatwe - już pokazaliśmy, że saldo może pochodzić z historii modelu domeny, i to jest sposób, w jaki oczekuje się, że usługa salda to zrobi.
Podsumowując; W dowolnym momencie możesz wczytać historię modelu domeny, zapytać o jej stan, a także wczytać historię procesora zdarzeń, aby określić, jakie prace jeszcze nie zostały potwierdzone.
Uczciwa odpowiedź (+1). Mocna dawka rzeczywistości. Obecnie korzystam z pojedynczego RDBMS zamiast oddzielnych magazynów danych pochodzących z wydarzeń. –
Miałem nadzieję, że wydarzenie będzie zawierało wzorce obejmujące dość podstawowe scenariusze. Ale może rzeczywistość jest taka, że to wciąż wczesne dni. Chociaż w pełni doceniam Pana radę, mam nadzieję, że nie poczujecie się urażeni, jeśli nie od razu uzna to pytanie za poprawne. Wciąż mam nadzieję, że istnieją wzorce lub pojawią się w ramach event-sourcingu, który obejmie takie scenariusze. –
@ILICH Zgadzam się, że ostateczna spójność nie jest warunkiem wstępnym pozyskiwania zdarzeń. Jednakże jedną dobrą heurystyką wyboru pomiędzy ostateczną i natychmiastową spójnością jest ustalenie, czy to odpowiedzialność użytkownika końcowego, czy organizacja/system ponosi odpowiedzialność za zapewnienie spójności danych. Jeśli chodzi o wszystkie skutki uboczne związane z ujemnym saldem na rachunku bankowym, sądzę, że można bezpiecznie powiedzieć, że sam bank jest bardziej odpowiedzialny niż konkretny operator, a system pozapasmowy wydaje się być najlepszym miejscem do poradzenia sobie z tym problemem. – guillaume31