Czym Jest Event Sourcing i Dlaczego Warto Się Tym Zainteresować?

pytanie zadane 8 lutego w Algorytmy przez migatotech Początkujący (390 p.)

Hej Forumowicze!

Odkryłem ostatnio temat, który wydaje się być kluczowy dla przyszłości rozwoju oprogramowania, a mianowicie Event Sourcing. Jest to pojęcie, które może brzmieć skomplikowanie, ale jego zrozumienie otwiera przed nami nowe możliwości w projektowaniu systemów. Zastanawiam się, czy to może być ten element, który zmieni sposób, w jaki tworzymy aplikacje?

Event Sourcing, mimo że jest fundamentem dla wielu nowoczesnych systemów, często pozostaje niezrozumiany dla szerokiego grona deweloperów i architektów. Właśnie z tego powodu postanowiłem zgłębić ten temat i podzielić się z Wami tym, co udało mi się dowiedzieć.

Stworzyłem film, który służy jako wprowadzenie do Event Sourcing - wyjaśnia, na czym polega to podejście, jakie problemy rozwiązuje i dlaczego może być wartościowe dla naszych projektów. Chciałem, aby było to proste i przystępne wprowadzenie, które nie zanurza się zbyt głęboko w techniczne szczegóły, lecz otwiera drzwi do dalszego eksplorowania tematu.

https://www.youtube.com/watch?v=umsR5d7uZOw

Mam nadzieję, że znajdziecie chwilę, aby się z nim zapoznać. Bardzo jestem ciekaw Waszych pierwszych wrażeń i czy temat wydał Wam się tak intrygujący, jak mnie.

Czy ktoś z Was już eksplorował głębiej Event Sourcing? Może macie jakieś własne przemyślenia lub zasoby, które pomogły Wam lepiej zrozumieć ten wzorzec? Chętnie zobaczę Wasze opinie i zasoby w komentarzach!

Pozdrawiam i do zobaczenia w dyskusji! ‍

komentarz 8 lutego przez reaktywny Nałogowiec (41,050 p.)

Super! W weekend obejrzę. Ta koncepcja nie jest nowa, słyszałem o tym chyba ponad 10 lat temu.

1	komentarz 8 lutego przez migatotech Początkujący (390 p.) Zdecydowanie nie jest nowa, ale mam wrażenie, że ostatnimi czasy cieszy się ona nowym życiem

komentarz 8 lutego przez reaktywny Nałogowiec (41,050 p.)

Obejrzę i w najbliższych dniach dam znać - ocenie film.

komentarz 10 lutego przez marcin99b Szeryf (82,180 p.)
edycja 10 lutego przez marcin99b

mam wrażenie, że ostatnimi czasy cieszy się ona nowym życiem

czy ja wiem, mam wrażenie że "nowe życie" to były okolice 2015-2018, teraz to jest raczej jedno z standardowych podejść, które sie wybiera albo nie

google trends potwierdza moją teorie, w 2015 coś wystrzeliło i rosła popularność aż do szczytu w 2018, a później to było coś takiego zwykłego

słyszałem o tym chyba ponad 10 lat temu

Martin Fowler pisał o tym jeszcze w 2005, w sumie ciekawe kiedy były takie dosłowne początki

a tutaj np https://www.computerworld.com/article/2570503/event-driven-architecture-poised-for-wide-adoption.html w poście z 2003 opisywali że pewnie w 2007 to będzie mainstream

komentarz 14 lutego przez jankustosz1 Nałogowiec (35,880 p.)

@migatotech, hmm. Fajny materiał, ale mam wrażenie, że w firmie gdzie pracuję takie podejście byłoby bardzo niewydajne. Jest tabela SQL'owa która może ważyć nawet kilkanaście gigabajtów w największych firmach klientów. Może zostać zmieniony dowolny rekord z tej tabeli. W takim przypadku każdy snapshot musiałby robić jej kopię? Po pierwsze to strasznie wolne, po drugie zaraz by się skończyła pamięć na serwerze.

komentarz 14 lutego przez marcin99b Szeryf (82,180 p.)

możesz spojrzeć na to jak działa redux, masz zapisany obecny stan, ale masz też całą historie zmian po której możesz sprawnie sie przesuwać

to nie jest dobre podejście do wszystkiego, tak jak w sumie każde

zyskujesz łatwe przemieszczanie sie po historii, możesz szybko podejrzeć stan danych X dni wstecz, jak coś sie zepsuje to możesz łatwo cofnąć sie w czasie, ale tracisz na tym że musisz gdzieś trzymać tą historie zmian

git też działa w ten sposób, masz commity które są informacjami kiedy była jaka zmiana, dzięki temu możesz sprawnie wracać do przeszłości

komentarz 15 lutego przez migatotech Początkujący (390 p.)

@jankustosz1, tak się składa, że dzisiaj opublikuję film gdzie robię porównanie baz danych dla event sourcingu, więc zapraszam :)
Event sourcing prawdopodobnie by sprawił, że baza byłaby jeszcze większa, ale to nie znaczy, że niewydajna. Snapshoty są oddzielną tabelą, w której przechowujesz stan bazy - robisz je np. raz dziennie (częstotliwość zależna jest zazwyczaj od ilości napływających eventów). Idea event sourcingu jest również taka, że zdarzenia są niemultowalne, więc nie mamy prawa ich modyfikować. Niesie to ze sobą kolejne problemy i są do tego potrzebne jeszcze inne rozwiązania - np. wersjonowanie eventów (o problemach z tym wzorcem również zrobię film jak już przejdę przez kolejne etapy potrzebne do skutecznej implementacji)

3 odpowiedzi

odpowiedź 9 lutego przez Ehlert Ekspert (212,710 p.)

Generalnie spoko, fajnie wytłumaczone. Jedyne co mi średnio pasowało to nomenklatura: snapshoty to bardziej zrzuty stanu danego agregatu, które przyspieszają kalkulację. Tzn na obecny stan agregatu składa się 5.5k eventów, więc po 5k (w zależności od potrzeb) robimy snapshot. Wtedy żeby uzyskać stan rzeczywisty apply przetwarza tylko 500 zdarzeń. I tego potrzebujemy na warstwie command busa - np do walidacji. W filmie użyłeś terminu snapshot w kontekście read modelu, którzy rzeczywiście jest (aczkolwiek nie zawsze) tworzony asynchronicznie.

Ogólnie spoko, kibicuję

odpowiedź 9 lutego przez Jacek0325 Obywatel (1,070 p.)

Hej! Ja za dużo nie wiem o event sourcing i chciałem w odpowiedzi zadać pytanie

Bo tak jak to sobie wyobraziłem, oglądając twój film, to w bazie danych systemu mogłyby być dwie tabele. Jedna by przechowywała wszystkie eventy od początku, a druga te snapshoty, generowane co jakiś czas i pokazujące np. stan magazynu. I każdy snapshot miałby przypisane id eventu, po którym został wygenerowany, dzięki czemu program by wiedział, od którego eventu obliczać nowego snapshota. Dobrze to sobie wyobraziłem?

Gratuluję stworzenia filmu, pozdrawiam!

komentarz 10 lutego przez migatotech Początkujący (390 p.)

Ogólnie tak, masz dobre wyobrażenie (w przyszły czwartek będę robił rozszerzenie tematu, na które już teraz zapraszam :) )

Potrzebujemy tabeli dla eventów, potrzebujemy tabeli dla snapshotów no i te nasze eventy trzeba do czegoś (jakiegoś agregata) podpiąć, więc to będzie kolejna tabelka.

komentarz 10 lutego przez Jacek0325 Obywatel (1,070 p.)

Hmm, no ja na razie tej koncepcji kolejnej tabeli nie rozumiem. Oczywiście nie naciskam, żebyś mi wytłumaczył, skoro i tak będziesz o tym opowiadał w filmie.

Przeczytałem definicję agregacji w programowaniu, i to jestem w stanie zrozumieć, bo uczyłem się o kompozycji w Java, która jest szczególnym przypadkiem agregacji. Ale agregatów w bazach danych na razie nie zgłębiłem.

odpowiedź 13 lutego przez reaktywny Nałogowiec (41,050 p.)

Wiem, że pytam od podstawy podstaw, ale może kiedyś będziesz miał czas na zajęcie się problemem podziału portalu na mikroserwisy. Ja TUTAJ nawet rozpocząłem wątek w tym temacie.

komentarz 15 lutego przez migatotech Początkujący (390 p.)

Myślę, że zrobię kiedyś o tym film, natomiast tymczasem dam Ci linka do strony, która może dać Ci informacje do przemyślenia jak podejść do tego tematu

https://microservices.io/patterns/refactoring/strangler-application.html