Zaimplementowanie źródła zdarzeń

Podstawowy pomysł

Event Sourcing jest wzorcem przechowywania stanu systemu jako ciąg zdarzeń. Zamiast trzymać aktualny stan, zapisujemy każdą zmianę, która nastąpiła – każde zdarzenie reprezentuje wykonaną operację.

Ten podejście pozwala na odtworzenie stanu systemu w dowolnym momencie czasu poprzez powtórne przetwarzanie tych zdarzeń, oferując kompleksowy ślad kontroli i umożliwiając różne modele czytelne dla różnych przypadków użycia.

Zapisywanie zdarzeń jako niezmienne rekordy

Aby utrzymać integritę danych, używaj kontroli współczesności optymistycznej podczas aktualizacji rekordów zdarzeń. Oznacza to założenie, że żaden inny proces nie zmodyfikował rekordu od chwili jego ostatniego odczytu.

Dla dużych agregatów tworzone są szkicowe obrazy – okresowe podsumowania stanu – aby zmniejszyć wymagania w zakresie przechowywania i poprawić wydajność zapytań dla historicznych widoków.

demo na żywo · powiązana symulacja● LIVE

Zapisz wszystkie zdarzenia do celów kontrolnych

Event Sourcing jest szczególnie odpowiednie dla systemów wymagających szczegółowych śledztw kontrolnych, co pozwala na odtworzenie stanu systemu w dowolnym momencie czasu. Jest również idealny dla skomplikowanych zasad biznesowych lub sytuacji, gdzie są potrzebne różne modele czytelne.

Jednak nie jest najlepszym wyborem dla prostych operacji CRUD bez zaawansowanej logiki, ponieważ podejście oparte na zdarzeniach może dodatkowo skomplikować system.

Często zadawane pytania

Czy błędy w komendach powinny generować zdarzenia?

Błędy w komandach nie powinny wywoływać zdarzeń; zamiast tego, powinny rzucać wyjątki. W przypadku błędu w projekcji, zaimplementuj kolejkę zmarzniętą dla nieudanych wiadomości, zaloguj błędy i utrzymaj mechanizm powtarzania do ponownego przetworzenia ich.

Co to jest Event Store – specjalistyczna baza danych do przechowywania zdarzeń?

Event Store to specjalistyczna baza danych zaprojektowana w celu przechowywania strumieni zdarzeń. Popularne rozwiązania obejmują EventStore DB, Apache Kafka (jako dziennik zdarzeń), AWS EventBridge oraz niestandardowe implementacje na PostgreSQL lub MongoDB – najlepszy wybór zależy od Twoich wymagań dotyczących wydajności, skalowalności i funkcji.

Jak powinno się przetestować agregaty za pomocą podanej-kiedy-tesz?

Użyj metody testowania podana-kiedy-tesz: Dany zestaw zdarzeń, kiedy wykonać komendę, to zweryfikować wynikające z niej zdarzenia. Testuj projekcje powtarzając zdarzenia i walidując stan modelu czytelnego – co zapewnia zgodność między różnymi widokami.

Są zdarzenia w Event Sourcingie zwykle niemutowalne?

Tak, zdarzenia w Event Sourcingie są ogólnie niemutowalne i nigdy nie usuwane. Dla celów przestrzegania norm prawnych, możesz zaimplementować arhivistykę zdarzeń (przeniesienie starszych zdarzeń do magazynu chłodnego) lub szyfrowanie zdarzeń – szczególnie ważne dla spełnienia wymagań GDPR, gdzie można archiwizować dane osobowe po określonym okresie przechowywania.

▶ Wypróbuj na żywo

Wszystko powyżej działa bezpośrednio w Twojej przeglądarce — otwórz Hash Function Avalanche Visualizer i zmieniaj parametry podczas działania. Nic nie jest instalowane ani przesyłane na serwer, cały model działa w jednej karcie.

▶ Otwórz symulację Hash Function Avalanche Visualizer