Jak event-sourcing zmienia podejście do projektowania aplikacji

Event-sourcing to podejście do projektowania aplikacji, które wykorzystuje zdarzenia jako główne źródło informacji oraz przechowuje je w postaci sekwencji. Każde zdarzenie reprezentuje zmianę w stanie aplikacji i jest traktowane jako nieodwracalne. To podejście zapewnia wiarygodne śledzenie historii działania aplikacji oraz umożliwia łatwe przywracanie do dowolnego punktu w czasie.

Strumień zdarzeń jako podstawa pracy aplikacji

Event-sourcing to podejście do projektowania aplikacji, w którym dane są przechowywane w formie strumieni zdarzeń, czyli kolekcji niezmienialnych zapisów dotyczących wszystkich operacji na danych. Taki strumień stanowi główną bazę danych dla aplikacji, a każde nowe zdarzenie jest dopisywane na końcu strumienia. Dzięki temu każda zmiana danych jest reprezentowana jako nowe zdarzenie, a dostęp do historii danych pozwala na łatwe analizowanie i wyciąganie wniosków. Przy projektowaniu aplikacji korzystającej z event-sourcingu ważne jest odpowiednie zaprojektowanie strumienia zdarzeń, który będzie spełniał wymagania biznesowe i umożliwiał łatwe odwzorowanie stanu aplikacji.

Odrzucenie tradycyjnej struktury bazy danych

Jedną z kluczowych kwestii, która wynika z podejścia event-sourcing, jest konieczność odrzucenia tradycyjnej struktury bazy danych. Zamiast przechowywać ostatni stan obiektu, jak ma to miejsce w podejściu CRUD, event-sourcing wymaga przechowywania historii wszystkich zmian, które zostały wprowadzone. Oznacza to, że każde zdarzenie jest zapisywane oddzielnie, a baza danych zamiast struktury tabelarycznej składa się z zapisanych zdarzeń.

Histereza - dlaczego czasami zdarzenia mogą być odpowiedzią na zapytania

W podejściu tradycyjnym do projektowania aplikacji często zapytania kierowane są do bazy danych w celu pobrania aktualnego stanu encji. Jednak zastosowanie architektury opartej o event-sourcing pozwala na przejście do modelu, w którym przechowywane są jedynie zdarzenia, a stan encji jest odtwarzany na bieżąco na podstawie historii tych zdarzeń. W takim podejściu występuje zjawisko histerezy, czyli opóźnienia między wykonaniem zdarzenia a jego wpływem na stan encji. W rezultacie zapytania kierowane są do bazy z wyprzedzeniem, by w momencie ich wykonania otrzymać aktualną wartość encji. Zdarzenia stają się w tym przypadku odpowiedzią na zapytania, dzięki czemu również zapytania z ostatniej chwili są w stanie uzyskać poprawną odpowiedź.

Różnice między projektowaniem aplikacji opartych o zdarzenia a tradycyjnym podejściem

W podejściu tradycyjnym projektujemy aplikację jako system, który reaguje na wejściowe akcje użytkownika, tworząc nowy stan aplikacji. Zdarzenie jest jedynie reakcją na poprzednie akcje. W przeciwieństwie do tego, w podejściu opartym o zdarzenia, wszystko co dzieje się w aplikacji jest zdarzeniem. Zamiast tworzyć nowy stan aplikacji, dodajemy kolejne zdarzenia. Dzięki temu możemy łatwo przeglądać historię zmian i odtwarzać stan aplikacji w dowolnym momencie.