Mireczki pytanie.
Załóżmy, że chcę zbudować serwis w oparciu o #eventsourcing
Gdzie trzymacie wszystkie zdarzenia? W bazie noSQL-owej? A w bazie relacyjnej wyliczone finalne wartości (te tzw. projekcje)?

Przecież po 2,3 i np. 5 latach działania takiego systemu eventów będę miał od cholery, baza SQL-owa raczej tego nie utrzyma.

#programowanie
@Dyktus: Często się do tego stosuje np. kafkę + cassandrę. Eventy konsumujesz z kafki z cassandry odbudowujesz stan aplikacji w razie jakiegoś padu lub gdy potrzebujesz wyciagnąć coś starego czego na kafce już nie znajdziesz
  • Odpowiedz
Drodzy Mirki spod #programowanie mam taki dylemat z #eventsourcing. Otoz przypuscmy, że mam sobie ranking graczy, który buduje punktację za jakieś aktywności, np daje 5 pkt za zabicie wroga i 1pkt za uratowanie zakladnika. Tabela rankingu będzie wyglądać mniej więcej tak:
Miejsce | gracz | zabitych | urattowanych | suma.
Jak powinienem zapisywać zdarzenia i z czego odtwarzać stan? Czy zapisywać efekt typu gracz x zabił wroga
@kefas_safek: piszesz strzelankę w php ? proponuję notować wszystkie zdarzenia, zarówno zabicia wrogów jak i zdobyte achievementy, ponieważ zasady mogą zmieniać się w czasie, np zrobisz promocję na święta, że za trzech zabitych wpada medal, gdzie normalnie trzeba typów zabić dziesięciu. No i wtedy jak to przeliczysz wstecz mając tylko tabele z zabitymi ?
  • Odpowiedz
@kefas_safek: ja tam bym zrobił
Timestamp, x zabił y,
Timestamp, x uratował zakładnika
...

No i nawet jak ci się zmieni punktacja w czasie to będziesz mógł uwzględnić.
  • Odpowiedz
W event sourcingu możemy zdefiniować wiele handlerów dla jednego typu zdarzenia. Jaką konwencję organizacyjną handlerów przyjęlibyście w takiej sytuacji:

System A wysysła do B wiadomość. System B po odebraniu wiadomości emituje zdarzenie MessageReceived. W wyniku tego zdarzenia mają wykonać się następujące operacje:
- zapis informacji do logu aplikacji o odebranej wiadomości,
- umieszczenie wiadomości w kolejce, skąd zostanie odebrana przez inny system
- wysłanie informacji o odebranej wiadomości do serwisu odpowiedzialnego za monitorowanie obsługiwanych zdarzeń w czasie rzeczywistym (ASP.NET i SignalR)
markaron - W event sourcingu możemy zdefiniować wiele handlerów dla jednego typu zdar...

źródło: comment_Z8kISSVB9OfJ2yRUUpdxx7usuXWd5L7V.jpg

Pobierz
  • Odpowiedz
Ktoś tutaj interesuję się #eventsourcing ?
Zadam może już teraz pytanie.

Czy w event sourcingu jedna instancja agregat root reprezentuje pojedynczy byt biznesowy?
Chodzi mi o to jak zabezpieczyć taki agregat przed dostępem z wielu wątków?
Z tego co rozumiem w całym systemie może istnieć tylko jedna instancja bytu biznesowego i wszystkie komunikaty związane z np tym kontem bankowym idą tylko do tej jednej instancji? Agregat root obsługuje w danym momencie tylko jeden komunikat, a reszta jest kolejkowania?
Jest dokładnie jak napisałeś. Aktorzy w akce obsługują jeden message na raz, a reszta jest skolejkowana w mailboxie.
  • Odpowiedz