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.

Czy szukasz wykonawcy projektów IT ?

Sprawdź case studies

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ź.

Nieodwracalność zdarzeń – jak wpływa na modelowanie domeny?

W tradycyjnych systemach CRUD operacje na danych mogą być odwracalne – rekordy można aktualizować i usuwać, co prowadzi do utraty wcześniejszych wartości. W podejściu event sourcingu każde zdarzenie jest nieodwracalne i zapisywane jako część historii systemu. Oznacza to, że stan aplikacji nie jest zmieniany bezpośrednio, a jedynie rekonstruowany na podstawie kolejnych zdarzeń.

Taka nieodwracalność zmusza do innego modelowania domeny – zamiast myśleć o modyfikacji obiektów, projektujemy system w oparciu o zdarzenia, które opisują fakty zaistniałe w aplikacji. Zmienia to perspektywę, czyniąc system bardziej odpornym na błędy i umożliwiając łatwiejsze audytowanie operacji. W efekcie mamy pełną historię zmian, co jest szczególnie przydatne w systemach finansowych, medycznych czy wszędzie tam, gdzie kluczowa jest transparentność danych.

Eventual consistency – czy spójność w czasie rzeczywistym jest konieczna?

W systemach opartych na event sourcingu spójność danych nie jest gwarantowana natychmiastowo. Zamiast tego stosuje się model eventual consistency, w którym różne części systemu mogą mieć chwilowo różne stany, ale w końcu osiągną spójność.

W wielu przypadkach taka asynchroniczność nie jest problemem – np. w systemach e-commerce użytkownik może od razu zobaczyć komunikat „Twoje zamówienie zostało złożone”, podczas gdy faktyczne przetwarzanie płatności i rezerwacja produktów w magazynie dzieje się w tle. Podejście to pozwala na lepsze skalowanie systemu, eliminację blokad baz danych i większą odporność na awarie.

Jednak nie zawsze eventual consistency jest akceptowalna – np. w systemach bankowych kluczowe jest, aby saldo konta było spójne natychmiast po wykonaniu przelewu. Dlatego w zależności od wymagań biznesowych event sourcing może być uzupełniany mechanizmami zapewniającymi silniejszą spójność dla krytycznych operacji.

Event Sourcing a CQRS – naturalne połączenie czy osobne podejścia?

CQRS (Command Query Responsibility Segregation) i event sourcing często idą w parze, ale nie są tym samym. CQRS zakłada oddzielenie operacji modyfikujących stan systemu (komendy) od operacji odczytu (zapytania). W klasycznym modelu CRUD te operacje często są realizowane na tych samych strukturach danych, co może prowadzić do problemów wydajnościowych i złożonych zależności.

Event sourcing naturalnie wspiera CQRS, ponieważ zamiast modyfikować rekordy, zapisuje zdarzenia, które mogą być później interpretowane w różny sposób w zależności od potrzeb. Dane do odczytu mogą być przetwarzane asynchronicznie i materializowane w zoptymalizowanych widokach (tzw. read models), co zwiększa wydajność systemu.

Mimo że CQRS i event sourcing często są stosowane razem, można je również rozdzielić. CQRS może funkcjonować bez event sourcingu, korzystając z klasycznych baz danych, a event sourcing może działać w systemie bez CQRS, gdzie odczyt bazuje na pełnej rekonstrukcji stanu. Wybór odpowiedniej kombinacji zależy od wymagań systemu i jego architektury.

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.