Co to jest Event Sourcing?
Event Sourcing to sposób tworzenia systemów w oparciu o przetwarzanie zdarzeń. To prawdziwy „buzzword” w branży IT oraz rozwiązanie, które niesie za sobą wiele korzyści, takich jak choćby:
- łatwe skalowanie aplikacji, przez podział na Command i Query (w połączeniu z CQRS) oraz procesy asynchroniczne,
- pełna „historia” zmian w agregatach, tzw. audytowalność,
- odtworzenie stanu aplikacji dla określonego czasu.
Z Event Sourcingiem, jak z każdym nośnym hasłem, nierozerwalnie jest też związanych wiele faktów i mitów, które dziś chcielibyśmy przybliżyć i obalić. Wszystko po, żeby pokazać, że nie taki Event Sourcing straszny, jak go malują. Zaczynajmy.
Fakty i mity na temat Event Sourcingu
1. Event Sourcing jest trudny
Event Sourcing nie jest trudny, jest po prostu inny. Podstawą zrozumienia i zamodelowania świata są tu zdarzenia, które w nim zachodzą i które mają wpływ na obiekty i relacje między nimi. Nacisk położony jest tu na zrozumienie procesów biznesowych. Event Sourcing wymaga więc zmiany myślenia i patrzenia z innej perspektywy.
2. Event Sourcing jest ciekawy, ale niepraktyczny
Procesy biznesowe to też „storytelling”. Warto więc modelować je jako zdarzenia, bo dobrze odzwierciedlają przepływ biznesowy. Jest to nie tylko bardzo ciekawe, ale przede wszystkim, wbrew obiegowej opinii – praktyczne – pozwala bowiem uprościć komunikację projektową do maksimum. Przez oparcie na zdarzeniach i swoje gawędziarstwo Event Sourcing jest po prostu bliższy rzeczywistemu światu. Dowód? DodanoElementDoKoszyka, ZaakceptowanoZamównienie, WystawionoFakturęProforma, DokonanoOpłaty, WystawionoFakturę, WysłanoZamówienie. Prościej tego przebiegu zdarzeń zakomunikować się chyba nie da.
3. Event Sourcing wymaga użycia CQRS, Domain Driven Design oraz innych ekstrawaganckich wzorców
Zarówno Event Sourcing, Domain Driven Design (DDD) jak i CQRS skupiają się na zrozumieniu procesów biznesowych i zamodelowaniu ich jak najwierniej w naszym oprogramowaniu. Dzięki ich zastosowaniu systemy informatyczne działają lepiej i są łatwiejsze w utrzymaniu. Wszystkie wymienione metodyki bardzo dobrze ze sobą współgrają, ale co ważne – ich wspólne wykorzystanie nie jest obligatoryjne. Mieści się ono raczej w kategorii „nice to have”, a nie „must have”.
4. Do Event Sourcingu potrzebne są dwie bazy, a jedną z nich musi być Mongo
Event Sourcing nie jest powiązany z konkretnym sposobem przechowywania danych. Kluczem do jego zrozumienia jest to, że prawdą w nim jest log zdarzeń. Tylko dokładny opis zdarzeń (o którym mowa w punkcie 3) pozwoli nam pozyskać aktualne dane Użytkownika. Aplikujemy zdarzenie jedno po drugim, począwszy od najstarszego do najnowszego. Ten proces zwany jest agregacją. Uzyskany w jego wyniku stan obiektu to z kolei projekcja. Każde zdarzenie możemy zapisać jako wiersz w tabeli „Zdarzenia”, a projekcję, jako wiersz zdarzeń w zwykłej tabeli relacyjnej. Oddzielenie modelu zapisu od modelu odczytu gwarantuje nam większe możliwości optymalizacyjne i rozdział logiczny. Do tego wszystkiego wcale nie są potrzebne dwie bazy – owszem, można z nich skorzystać, ale wcale nie jest to wymagane. Podobnie, jak wykorzystanie w tym celu Mongo.
5. Event Sourcing wymaga Eventual Consistency oraz szyny zdarzeń typu Kafka lub RabbitMQ
Eventual Consistency to gwarancja, że jeżeli dokonaliśmy jakiś zmian, to prędzej czy później zostaną one zaaplikowane. Nie wiemy, kiedy dokładnie, ale wiemy, że na pewno się to wydarzy. Event Sourcing wymaga Eventual Consistency, tak samo jak każdy inny storage. Zdarzenia można jednak przechowywać równie dobrze w bazie relacyjnej, tak więc, wbrew obiegowej opinii, Eventual Consistency wcale nie jest nam potrzebne. Co więcej, jeśli nie mamy potrzeby przesyłać tych zdarzeń dalej (np. do innych serwisów/modułów), to nie musimy używać także szyn zdarzeń takich jak wspomniana już Kafka czy RabbitMQ.
6. Event Sourcing ma problemy z wydajnością
Event Sourcing jest tak wydajny jak storage, który ma pod sobą.
Co więcej, ma on 2 podstawowe założenia związane właśnie ze storage:
- zdarzenia są niezmienialne (immutable),
- nie można zmienić przeszłości, można ją tylko inaczej zinterpretować, – zdarzenia dodaje się jedno za drugim, jak w kolejce (append only).
Dzięki tym założeniom storage może być zoptymalizowany pod sytuację, gdzie nigdy nie robimy „losowych aktualizacji rekodów”. Dzięki temu tabela zdarzeń może działać szybciej, bo:
- będą tylko inserty na końcu,
- nie będzie w niej nigdy aktualizacji,
- odczyt będzie robiony tylko po kluczu.
Właśnie dlatego Event Sourcing nie tylko nie powinien być wolniejszy, ale może być nawet szybszy niż tradycyjne rozwiązania.
7. Event Sourcing jest trudny w utrzymaniu
Event Sourcing nie jest dziecinnie prosty, ale które oprogramowanie nie jest trudne w utrzymaniu? Chyba tylko to, które nie dotarło na produkcję. Problemy migracji i spójności danych w systemach rozproszonych, są skomplikowane, ale nie są wcale mniejsze, gdy używamy rozwiązań klasycznych/relacyjnych. W systemach opartych na zdarzeniach ujawniają się one po prostu szybciej.
Jak widać – Event Sourcing ma wiele zalet, ale, jak wszystko, ma również i swoje ograniczenia oraz pewne charakterystyczne kwestie, o których należy pamiętać i które należy mieć na uwadze, w zależności od specyfiki konkretnego projektu. To podejście, które ma swoich zwolenników i przeciwników. Podejście, które wykorzystane w rozsądny sposób naprawdę może przynieść wiele korzyści.
Więcej informacji o Event Sourcingu możecie zasięgnąć u Oskara Dudycza. Polecamy też odwiedzenie jego profilu GitHub.
Pełna treść publikowanego tutaj podsumowania wad i zalet Event Sourcingu dostępna jest na: https://www.szkola-event-sourcing.pl/
