Łukasz Kałużny: Cześć Słuchacie Patoarchitektów prowadzą Łukasz Kałużny…

Szymon Warda: …I Szymon Warda. Wszystkie linki do tego odcinka oczywiście na patoarchitekci.io/69.

Łukasz Kałużny: No dobra Szymonie, to dzisiaj o czym?

Szymon Warda: Dziś będzie o event sourcingu, to chyba nasz ulubiony temat do nabijania się, ale dzisiaj będzie w wersji poważnej.

Łukasz Kałużny: Tak - i robimy wprowadzenie. Wzięliśmy osobę, która pomoże nam dzisiaj i odpowie nam na nasze pytania, wątpliwości, rzeczy, z których też się nabijamy. Zaprosiliśmy osobę, którą u mnie w telefonie jest taką właśnie jeżeli chodzi o event sourcing albo trudne projekty, gdzie ktoś chce rozważyć event sourcing, to jest taki numer jeden w moim telefonie, żeby zadzwonić albo napisać… I jest z nami dzisiaj Oskar Dudycz. Oskar udziela się bardzo sporo na temat event sourcingu, był ewangelistą w event storze. Jest mainteinerem Martena, czyli event sourcingu dla dotneta z wykorzystaniem Postgress SQLa + tworzy dużo opensource’owych rzeczy, przykładów i hejtuje trochę technologie pokazując, że powinniśmy robić to prościej i logiczniej. Co jest z naszym podejściem bardzo zgodne, co do tego jak my widzimy technologię. Cześć Oskarze!

Oskar Dudycz: Cześć! Dzięki. Aż się zarumieniłam. Bardzo ładne wprowadzenie. Dziękuję bardzo. Delikatnie ująłeś to, że gdzieś tam się pojawiam w Event Sourcingu. Ja już mam wrażenie, że niektórzy chyba tylko już w lodówce mnie widzą jak otwierają, także…

Szymon Warda: Raczej jesteś synonimem event sourcingu - jak się wpisuje event sourcing, to się pojawiasz Ty, tak. To się zgadza.

Łukasz Kałużny: Dokładnie, jak i powoli EDA również, jak jeszcze ją trochę pohejtujesz.

Oskar Dudycz: Ja się śmieję, że jestem wierzącym praktykującym, także…

Łukasz Kałużny: Dobre.

Szymon Warda: To jak mamy mówić o event sourcingu? Teraz przejdziemy do konkretów. To w takim… Wytłumacz event sourcing. Czy można tłumaczyć event sourcing - jak dla pięciolatka albo dla biznesu? Jedna… to w sumie tożsame, można powiedzieć, niemalże.

Oskar Dudycz: OK. To najpierw pierwszym pytaniem, które mogłoby paść jest… Czy wiesz jak działa księgowość? Jeśli odpowiedź by brzmiała tak, no to mógłbym od razu powiedzieć: to wiesz, jak działa event sourcing. Ale żeby nie iść na łatwiznę, to event sourcing… Jest to wzorzec wytwarzania oprogramowania, w którym wynik każdej operacji biznesowej powinniśmy zapisać. I co więcej, przy podejmowaniu kolejnej decyzji powinniśmy pobrać wszystkie te nasze poprzednie decyzje dla danego obiektu biznesowego, czyli po prostu nie wiem, użytkownika, koszyka zakupowego itd. I dopiero na tej podstawie uzyskać nasz stan wiedzy i podjąć kolejną decyzję i zapisać kolejny fakt. No i tymi faktami są właśnie zdarzenia. I nazwa event sourcing pochodzi z tego, że właśnie zdarzenia są naszym źródłem prawdy. To tak wysokopoziomowo tak bym to mógł powiedzieć. Nie wiem, czy to by biznes zrozumiał, ale…

Łukasz Kałużny: No właśnie to jest zawsze ciekawe. Z księgowością jest to chyba genialne porównanie, że event sourcing jest jak właśnie księga przychodów i rozchodów pełna.

Szymon Warda: Tak, ale kto robił systemy księgowe - to gdzieś tam stwierdzą, że “a by edycja się taka przydała”, żeby to zostało, ale ogólnie rzecz biorąc tak.

Oskar Dudycz: Ja jak pracowałem w module księgowym to nasz biznes nam mówił, że możemy robić co chcemy dopóki na koniec dnia się wszystko zgadza.

Łukasz Kałużny: Tak, dobre. Słuchaj Oskar, a gdybyśmy zeszli bardziej technicznie do event sourcingu, czyli powiedzieliśmy sobie to jest ta prosta definicja. A dla osób, które jednak są techniczne, jak byś zdefiniował event sourcing?

Oskar Dudycz: To może też spróbuję najpierw od takiej prostej, rzekłbym nawet prostackiej definicji, czyli w tej najprostszej definicji technicznej. Event sourcing jest to wzorzec taki przechowywania danych, czyli mamy tam dwie struktury danych, zdarzenie, które jest tak jak mówiłem, jakimś faktem biznesowym zapisanym po każdej operacji biznesowej, czyli po każdej logice i mamy strumień zdarzeń, gdzie strumień to jest taka uporządkowana sekwencja. No i kluczowym aspektem event soucingu jest takie coś jak event store. I event store to jest właśnie baza danych, to podkreślę - baza danych właśnie do przechowywania zdarzeń. No i event stories z założenia to są takie bazy klucz-wartość, gdzie kluczem jest identyfikator strumienia. Czyli to można porównać do zwykłego klucza w bazie relacyjnej, a naszymi danymi jest po prostu sekwencja zdarzeń. Czyli zamiast trzymać jeden spłaszczony stan no to trzymamy całą historię tego, co się wydarzyło dla naszego obiektu. No i to tak wydaje mi się, to jest tak najprościej, jakby to można było powiedzieć. Taka nawet trywalizacja nieco event sourcingu, ale w praktyce tak to wygląda.

Łukasz Kałużny: Jeszcze dopytamy się o szczegóły.

Szymon Warda: Tak, no bo mówiłeś dużo o zdarzeniach. O to chodzi w event sourcingu. To teraz naturalnym elementem, który jest de facto… Pytanie wchodzi. A jak się do event sourcingu ma event-driven architecture. Czy jedno jest możliwe bez drugiego? I w którą stronę jest zależność?

Oskar Dudycz: To różnie ludzie mówią. Według mnie no to… Event sourcing jest jednym z wzorców, które… Architektury opartej na zdarzeniach. Ale gdzieś tam na granicach, powiedzmy event-driven architecture, bo event sourcing jest o tym jak najlepiej i jak najwydajniej rejestrować i je potem utrwalać - te wszystkie właśnie fakty, te zdarzenia, które się wydarzyły w naszym systemie. Z kolei event-driven architecture to jest jak łączyć ze sobą poszczególne elementy, jakiś workflowów, procesów biznesowych, czyli event sourcing, to jest trwałość danych, a z kolei Event-Driven Architecture skupia się na tym, jak orkiestrować, łączyć ze sobą poszczególne fragmenty systemu przy pomocy zdarzeń, czyli bardziej dane w ruchu niż dane takie utrwalone.

Łukasz Kałużny: Czyli jak na to popatrzymy, to event sourcing jest bardziej wzorcem składowania danych niż samym tym frontem, do którego wszyscy się przyzwyczaili? W EDA, event-driven architecture.

Oskar Dudycz: Tak, zdecydowanie, no event sourcing… W każdym razie, w moim rozumieniu; głównie skupia się na modelu zapisu, czyli jak najlepiej przeprowadzić naszą logikę biznesową i zapisać fakty i event sourcing i też event story dają możliwość publikowania informacji o tym, że nowe zdarzenie się pojawiło. I to jest ten element, który jest punktem styku z event-driven architecture. Ale wszystko, co potem się dzieje to już tak naprawdę nie ma znaczenia, czy my mamy event sourcing, czy bazy relacyjne, czy bazy dokumentowe. Wszystkie te same problemy, czy też zalety architektur opartych na zdarzeniach będą takie same, niezależnie od tego, którego wzorca użyjemy.

Szymon Warda: Czyli się zgadzamy, jak najbardziej. Przez wiele lat robiliśmy dobrze, super.

Łukasz Kałużny: To jest teraz Oskar takie pytanie, które pewnie już nie raz usłyszałeś, bo ja chyba sam nawet… I w projekcie mieliśmy taką kwestię tłumaczącą to wspólnie, czy wyobrażasz sobie, bo jak słyszymy właśnie event sourcing i jest ta EDA i ta całość… Jeszcze ludzie wyobrażają sobie, że będą posiadali jeden duży event store, którego wszyscy będą czytali, pisali. Będzie on uniwersalny i de facto dzięki temu tą część asynchroniczną… Tą kolejkowość będziemy w stanie jakoś częściowo wyrzucić i zastąpić je po prostu takim event storem.

Szymon Warda: To też dorzucę, że to jest jedna z takich promowanych często słyszę na konferencjach właśnie, że tak można zrobić de facto.

Oskar Dudycz: Wydaje mi się, że większość z tego wywodzi się z Kafki, którą ja nie uważam za event store, w każdym razie nie w rozumieniu event sourcingowym, ale uwaga… Niestety też te narzędzia event sourcingowe np. Event Store DB; Tak naprawdę można sobie uruchomić kilka klastrów, ale takim domyślnym rozwiązaniem jest jednak użycie tego jednego event stora. Więc musimy odróżnić tutaj dobrą praktykę od praktyki rzeczywistej i raczej dobrą praktyką jest to, żeby jednak traktować event sourcing jako wzorzec wewnątrzmodułowy. Ja go w ogóle nie nazywam wzorcem architektonicznym. To jest design pattern. Wzorzec obsługi, przechowywania danych - to nie jest coś, co powinniśmy z założenia aplikować globalnie na wszystkie systemy, czyli tak jak wybieramy czy użyjemy w tym module bazę dokumentową czy bazę relacyjną, czy key-value store, no to możemy dodać do tego równania też event store i event sourcing, ale zdecydowanie nie uważam tego, że powinniśmy współdzielić, o ile nasze narzędzia na to nam pozwalają, że nie powinniśmy współdzielić bazy, szczególnie w takim systemie rozproszonym, bo jeżeli mamy monolit albo mniejszą skalę no to ok, to możemy tak zrobić, ale.

Szymon Warda: Czyli w ramach modułu de facto.

Łukasz Kałużny: Czyli podsumujemy, że właśnie taki mikroserwis ma swój event store dedykowany, swoją przestrzeń. I tak jak przy każdym mikroserwisie przy tym mówimy, że jest właścicielem tych danych i tylko on ma dostęp i odczyt do tej całej warstwy. A że technicznie ileś tych event store’ów położymy na jednym infrastrukturalnym rozwiązaniu; to jest zupełnie oddzielna kwestia.

Oskar Dudycz: Tak, zdecydowanie. No i ja tutaj bym zalecał ogólnie te same praktyki, które stosujemy… Najlepsze… Co do tego jak dzielić i układać w pudełka nasze bazy danych w klasycznym podejściu.

Szymon Warda: To jeszcze jeden temat. Właśnie można powiedzieć, że trochę zacząłeś, ruszyłeś go i niejako potwierdzasz naszą szyderę. Ale żeby tak zadać pytanie wprost bardzo mocno, bo no… Już wiele lat się nabijamy właśnie. Event Sourcing na Kafce, tak czy nie?

Oskar Dudycz: No zdecydowanie nie.

Szymon Warda: O Boże, wreszcie, ktoś to potwierdził!

Oskar Dudycz: To znaczy, ogólnie ja jestem, podkreślę od razu - disclaimer. Ja w ogóle używałem Kafki. Lubię Kafkę. To jest bardzo fajne narzędzie.

Szymon Warda: Tak.

Oskar Dudycz: Ale nie do event sourcingu. I teraz dlaczego? Bo tak jak wspominałem, event sourcing to jest o tym, jak trwale przechowywać dane no i ogólnie przez trwale to raczej mamy na myśli bazę danych. I jeżeli patrzymy na Kafkę, to ona jest taką bazą danych… I jak moglibyśmy nazwać zapisywanie czegoś w pliku tekstowym bazą danych? W dużym naciągnięciu rzeczywistości moglibyśmy tak powiedzieć. Przyjmijmy, załóżmy optymistycznie, że ona jest w stanie trwale te dane przechowywać. No to niestety, ale Kafka sama w sobie brakuje takich elementów, które byśmy oczekiwali od event store’a. No bo tak jak wspomniałem, zależy nam na tym, żeby trwale przechowywać dane, umiejscawiamy event sourcing raczej w modelu zapisu. Czyli powinno nam zależeć na tym, żebyśmy byli w stanie podjąć decyzję na bazie aktualnych danych, żebyśmy mieli gwarancję, że nikt w międzyczasie nam tego stanu nie zmienił. No ok, można sobie bez tego radzić, ale zdecydowanie to upraszcza. Jednak większość programistów jest do tego przyzwyczajonych.

Oskar Dudycz: No i teraz tak: Kafka nie ma czegoś takiego jak optymistic concurrency. Czyli optymistyczna zbieżność. Jest taki ticket w Jirze, który ma oznaczony bardzo niski priorytet i jest to od iluś tam lat, wisi. Więc optymistyczna współbieżność daje nam to gwarancję, że jeżeli dwie osoby zapisały w tym samym czasie, no to ta druga dostanie informację, że to nie jest aktualny stan. W Kafce nie ma takiej możliwości. No i teraz tak: strumienie. I tu i tu mamy strumienie. Z tym, że w Kafce nacisk jest na to, żeby ona jak najefektywniej przenosiła dane z jednego miejsca do drugiego. Więc one nie muszą być takie granularne, bo powiedzmy mamy jakiś topic czy też partycję pod kątem modułu, pod kątem rodzaju encji. No jak sobie to podzielimy, to już jest też dłuższa dyskusja, ale raczej w event sourcingu to jeden strumień zdarzeń powinien odpowiadać jednej instancji obiektu. Czyli tak mówiąc w nomenklaturze bazy relacyjnej - jednemu wierszowi. Tylko że tu mamy całą historię tego, co się dla niego wydarzyło. A w Kafce nie jesteśmy w stanie tego zrobić w prosty sposób, bo Kafka ma maksymalną liczbę partycji, czyli fizycznie, gdzie możemy zagwarantować kolejność zdarzeń, która w event sourcingu jest kluczowa.

Oskar Dudycz: To w Kafce mamy 160 tysięcy partycji. W każdym razie na tyle, na ile ostatni raz patrzyłem, to 160 tysięcy w bazie danych rekordów. To jest raczej nieakceptowalne. Możemy to hashować, jakoś, umieszczać kilka rekordów na jednej partycji, ale z kolei w event sourcingu… Gdy przywracamy stan, powinniśmy pobrać wszystkie zdarzenia, odbudować nasz domyślny stan i na tej podstawie sobie podjąć kolejną decyzję. To tutaj jeżeli byśmy harowali, to musielibyśmy pobierać wszystkie inne rekordy i tak możnaby iść w nieskończoność. Ja takiej dyskusji z jakimiś ewangelistami Kafki miałem dużo i koniec końców to się sprowadza, że no ok, są w stanie wymyślić jakąś… Taki domek z kart, gdzie można byłoby te definicje event sourcingu naciągnąć, ale pytanie po co, skoro są do tego narzędzia, które są dedykowane i robią to dobrze, więc…

Łukasz Kałużny: Dobra, realnie muszę Ci jednej rzeczy pogratulować, bo wpisałem sobie, żeby znaleźć ten numerek. Wpisałem sobie właśnie Kafka optimistic concurrency i jest w googlu na pierwszym miejscu Twój wpis, w którym to dwa lata temu hejtujesz. Ja sobie wziąłem ten ticket, sprawdziłem. No to długo to wisi, bo już od 2015.

Oskar Dudycz: No więc to według mnie to jest ok że tak wisi, bo dla mnie to pokazuje, że po prostu marketing mówi swoje, a specjaliści techniczni mówią swoje i oni wiedzą, że to dla nich to nie jest scenariusz użycia, który oni chcą promować. To, że marketing sobie promuje ten scenariusz, no to całe szczęście jednak inżynierów Kafka ma sporo dobrych, choćby ten Stop Ford itd. No ale to jest marketing, nie.

Łukasz Kałużny: A nie Field City Oak, który uprawia marketing.

Oskar Dudycz: Tak.

Szymon Warda: A tak z ciekawości - jak myślisz skąd wzięło się to? Bo to jest dość dominujące podejście na rynku, że jeżeli właśnie mówimy o event sourcingu, to dużo osób domyślnie mówi - okay, to zróbmy to na Kafce. Masz odpowiedź, skąd się to wzięło?

Oskar Dudycz: Mam kilka poszlak. Na pewno confluent ma olbrzymie zasoby, pompuje w marketing. I ja się śmieję, że tak jak niektóre partie prawicowe mówią na prawo od nas już nikt. To confluent mówi, w świecie event-driven na prawo od nas już nikt, więc oni wszystkie wzorce event-driven chcą wciągnąć. Ale wydaje mi się, że też ta oryginalna definicja… Bo w sumie nikt nie wie, kto wymyślił event sourcing. Greg Young się śmieje, że Sumerowie w tym swoim pierwszym… No ale ta pierwsza definicja i to Greg Young nawet mówi, że Martin Fowler tą definicję, która jest najbardziej popularna event sourcingu, to ona jest taka, powiedziałbym nieco nieszczęsna w tym sensie, że ona jest bardzo nieprecyzyjna, więc można pod nią podciągnąć bardzo dużo, w tym właśnie to, że po prostu zapisujemy zdarzenia i je potem nasłuchujemy na nie, bo w większości przypadków tak to kiedyś było, choćby jakiś wzorzec obserwator, powiadomienia… Wydaje mi się, że wszystko po trochę.

Łukasz Kałużny: Cały, Oskar, ten Enterprise Integration Pattern, które gdzieś tam powstało na początku lat dwutysięcznych i całe SOA wtedy.

Oskar Dudycz: Tak. Wydaje mi się, że tak wszystko po trochę, nie? Ale najbardziej bym winił tutaj w ostatnich latach marketing Confluent i no wiecie sami zresztą, bo przecież to wasz podcast jest o tych różnych patologiach i no tak niestety nasze działa industry, że wymyślamy sobie buzzwordy i potem je pchamy dalej.

Łukasz Kałużny: Raczej, chyba, jeszcze jak ktoś kupi ten support od confluenta, to jest na kogo zwalać potem ratowanie tego.

Oskar Dudycz: Tak.

Szymon Warda: Nie po iluś tam latach to się… Prędzej czy później to Jenga się zawali.

Oskar Dudycz: Ale na usprawiedliwienie, ja nie byłem, ale znam kogoś, kto był… Na Kafka Summit i tam nie ma takiego promowania event sourcingu. Tam zdaje się, są dużo bardziej pragmatyczne.

Łukasz Kałużny: No nie dziwię się. Słuchaj, to takie pytanie, jak jesteśmy… Pogadaliśmy trochę o technikaliach. Wróćmy teraz może bardziej do takich wzorców użycia. I pierwsze takie pytanie, które się nasuwa, bo mówimy, że event sourcing jest fajny, ma dużo zawiłości i innych rzeczy, ale jest de facto prostym wzorcem, bo to mamy takie trochę sprzeczne komunikaty i jakbyś powiedział, gdzie on generalnie się sprawdza jako wzorzec właśnie, tak jak powiedziałeś, jako strategia w naszych aplikacjach i jak często odradzasz? A jak często mówisz, że to jest kierunek, w którym warto żebyście poszli, tylko zrobili to poprawnie?

Oskar Dudycz: Ja z założenia nie widzę takiej sytuacji z automatu, gdzie on by się mógł nie sprawdzić, ale widzę sytuacje, kiedy… No nie dałby jakieś dodatkowej wartości i przede wszystkim największą wartość no to widzę tam, gdzie mamy bardziej złożony proces biznesowy, czyli taki wielokrokowy, gdzie chcielibyśmy zrozumieć i mieć możliwość taką… Diagnostyki. Już nie mówię audytu, bo to możemy bez event sourcingu zrobić, ale właśnie takiej diagnostyki i lepszego zrozumienia procesu, ewentualnie jeżeli byśmy chcieli mieć taki większy wkład w sensie takie dosyć granularne informacje. Ja najczęściej używam takiego dosyć trywialnego, który wygląda nieco CRUDowo scenariusza, czyli koszyk zakupowy. No i zobaczcie, że nawet w koszyku zakupowym mamy tych kroków kilka, bo możemy dodać produkt, usunąć, potwierdzić, zdefiniować przesyłkę i tak dalej. I nawet jeżeli ten scenariusz jest dosyć prosty i wydaje się zróbmy CRUDa, to zobaczcie, że z tych wszystkich danych choćby właśnie, które produkty były razem wybierane, które koszyki były opuszczone, biznes jest w stanie bardzo dużo ciekawych informacji wyciągnąć. Więc tak długo jak te informacje będziemy mieć trwale zapisane w naszej bazie danych, to potem możemy nawet do tyłu sięgnąć czy to biznes, czy to nawet my, bo możemy sobie wziąć sekwencję zdarzeń dla naszego rekordu jako programiści i po prostu nawet użyć do zdebugowania lokalnie, żeby zobaczyć, że ok, te pierwsze trzy zdarzenia wszystko szło dobrze, a przy czwartym się coś wywaliło.

Oskar Dudycz: Więc po pierwsze właśnie takie wielokrokowe scenariusze, przepływy i potem jako wkład do analityki danych, chociaż też niestety, ale jeszcze event story same w sobie nie mają takich wbudowanych narzędzi do analityki, więc do tego raczej trzeba użyć czegoś co jest dedykowane. Na kiedy się to nie sprawdzi… Wydaje mi się, że przede wszystkim się nie sprawdzi, kiedy czynnik ludzki jest oporny.

Łukasz Kałużny: Przepraszam. Wiedziałem, wiedziałem, miałem się o to zapytać, więc trafiłeś po prostu w sedno tego problemu, który ja widzę rynkowo.

Szymon Warda: A to teraz ja trochę naprowadzę. Bo mówimy sobie, gdzie się sprawdzały, gdzie się nie sprawdzało. Mówimy o tych ogólnie event, event story, ale teraz jakbyśmy tak poagregowali, co było wspólne na poziomie technicznym? Zejdźmy już na poziom mięsa. Generalnie. Jeżeli ma się udać, to co? A jeżeli ma się nie udać, to co wybierać? No nie? To w agregacie… Byśmy spojrzeli.

Oskar Dudycz: No to tak. Takie składniki, które muszą zajść albo powinny zajść. Po pierwsze no to niestety, ale czynnik ludzki i niekoniecznie to muszą być ludzie, którzy zjedli zęby na event sourcingu, bo takich nie ma za dużo. Ale ludzie, którzy chcą się uczyć i ludzie, którzy jeżeli chcą się uczyć i nie mają czasu, no to lepiej, żeby jednak był ktoś, kto cokolwiek z tym robił, żeby był w stanie wdrożyć innych. Jeśli mają czas, no to tych materiałów się pojawia coraz więcej, choćby mój blog. Ale już technicznie. Ważną rzeczą jest to, żeby się też rozeznać odnośnie tych implementacji event store’ów, które są w danej technologii, w której pracujemy. Bo tak jak sam event sourcing powiedziałem, jest wzorcem dosyć prostym. No ale to już też omówiliśmy, że dużo można pod to podciągnąć. No i na przykład Marten pod spodem ma Postgress, więc dostajemy wszystkie te gwarancje, które daje nam baza relacyjna, czyli transakcyjność, możliwość nawet odbudowy read modeli w tym samej transakcji, co dodajemy zdarzenia. Z kolei Event Store DB bardziej celuje na skupienie na właśnie obsłudze samej zdarzeń i to jest baza, która została stworzona.

Oskar Dudycz: Nie ma żadnej innej pod spodem, ale też nie ma np. modeli odczytu. Nie ma możliwości jakiegoś hackowania i zapisywania zmian więcej niż w jednym strumieniu, czyli więcej niż jednym agregacie w ramach jednej transakcji. Więc te Event Story potrafią się dużo różnić od siebie, więc to trzeba też sprawdzić, bo jeżeli mamy zespół, który się uczy, to może na początku… No to nie jest może idealna rada, ale no jak się uczymy, to raczej trochę pohackujemy i potrzebujemy sobie pohakować. Więc może też użyjmy bazy albo rodzaju event store’a, który nas tutaj jakoś nie uderzy. No i w event sourcingu… Bardzo ważne jest jednak, żeby zrozumieć te podstawowe aspekty modelowania, no bo pamiętajmy, że to jest wzorzec przechowywania danych, czyli tak jak w bazach relacyjnych normalizujemy dane - w bazach dokumentowych denormalizujemy - no to w event sourcingu musimy się nauczyć jak robić, żeby trzymać te strumienie jak najkrótsze, bo jak one będą krótsze, to wszystko będzie lżej, będzie łatwiej z nimi pracować, wydajność będzie lepsza. Więc w event sourcingu tak naprawdę bardzo dużo jesteśmy w stanie problemów technicznych uniknąć poprzez odpowiednie modelowanie właśnie strumieni, czyli już tak konkretnie mówiąc, zamiast na przykład trzymać strumień jako historię wszystkich transakcji w kasie w Biedronce, to może trzymajmy strumień jako odpowiednik jednej zmiany kasjera w Biedronce i nagle zamiast kilkudziesięciu czy tam kilkuset tysięcy zdarzeń będziemy mieć, nie wiem, 100, 500 w ramach jednej zmiany i to już będzie dużo bardziej zarządzalne.

Oskar Dudycz: No więc to. No i potem dosyć ważną rzeczą jest jednak, żeby zrozumieć te rzeczy związane, opsowe i DevOpsowe, które w przypadku narzędzi tych event sourcingowych są nieco trudniejsze, bo one pod tym kątem są nieco mniej dojrzałe. Tak jak ogólnie event sourcing, event story są już dojrzałymi narzędziami, to w przypadku tematów opsowych i DevOpsowych to mają trochę więcej ostrych krawędzi. Znaczy mają wszystko to, co oczekujemy, ale może to być nieco trudniej.

Łukasz Kałużny: Dobra. Słuchaj, jest jedna rzecz, która mi się tutaj… Przy tym jak powiedziałeś, bo bodajże to chyba Greg Young powiedział, że każdy powinien napisać własnego event store’a, bo nie jest trudną rzeczą, że łatwo sobie to zaimplementować. I z Twojej perspektywy jaka jest teraz taka realność w dzisiejszych czasach, bo event sourcing gdzieś pod spodem musi umieć zrobić… Bardzo… Dobra biblioteka do event sourcingu musi umieć zrobić dużo rzeczy i powinna też gdzieś w teorii ułatwiać nam właśnie potem też wintegrowanie się w EDAA, w inne takie rozwiązania, jeżeli podejdziemy to jako na komponent całości, a nie samego użycia. Więc jak jest Twoim zdaniem z implementacją własnego event store’a?

Oskar Dudycz: Ja bym powiedział, że zachęcam każdego do napisania swojego event store’a, a potem użycia go w swoim produkcyjnym systemie. To jest ogólnie super frajda napisać taki event store. Nawet udało mi się w 25 minut to zrobić na prezentacji, ale umówmy się - nie zaczynamy naszego projektu od tego typu… O, napiszmy sobie bazę relacyjną, bo chcielibyśmy używać bazy relacyjnej. Może to zróbmy. No ok, możemy to zrobić tylko no tak jak w przypadku tego stwierdzenia, to każdy się puknie w głowę. To jakoś w przypadku event store’a to jakoś nie. Wydaje mi się, że to miałoby sens, gdybyśmy nie znaleźli takiego event store’a w naszej technologii, który jest dojrzały. I który ma jakichś ludzi, którzy aktywnie nad tym pracują. Ale jednak w większości technologii takowe już są, więc samo napisanie swojego event store’a jest faktycznie dosyć proste. Ale utrzymanie go, no to jest inna sprawa. To nigdy nie będzie raczej coś, na co my będziemy mieć dedykowany czas od naszego biznesu, więc prędzej czy później każde takie core’owe rozwiązanie raczej… Nie padnie ofiarą zerowego priorytetu. Dodatkowo jeżeli chodzi o sam zapis zdarzeń, no to jest dosyć proste.

Oskar Dudycz: Serializujemy, zapisujemy i tyle. To są dwie metody w teorii, które musi mieć event store. Dodaj zdarzenie na koniec strumienia, odczytaj wszystkie zdarzenia ze strumienia, ale jeżeli chcemy… A w event sourcingu zdecydowanie chcemy i potrzebujemy mieć read modele, no to sytuacja już się dosyć komplikuje. No bo potem jak zrobić, żeby wydajnie te read modele były aktualizowane? Jak zapewnić kolejność zdarzeń? Jak zapewnić odbudowę tych read modeli? No to są już sytuacje, które są nietrywialne. One może nie są ściśle związane z samym event sourcingiem, ale jeżeli się piszemy na event sourcing, no to to są rzeczy, które i tak będziemy musieli przerobić, więc lepiej żeby robił to ktoś według mnie, kto się na tym zna i komu za to płacą, albo chociaż hobbystycznie siedzi i to robi po godzinach jak ja na przykład.

Szymon Warda: Ja o to pytam, bo mówimy sobie o event sourcingu - widziałeś jakie są wartości, kiedy stosować event sourcing. Wszystko fajnie, a tak personalnie to, co ja widzę na rynku to jest, że event sourcing fajnie wygląda jako taki greenfield. Z reguły po x latach on często dąży do takiego totalnego braku utrzymania. No bo mówimy sobie, że możemy sobie trzymać wszystkie wiadomości we wszystkich wersjach i tak dalej, i tak dalej, nigdy tego nie zmieniać i w ogóle odtworzyć się od startu czasu sprzed 15, 20 lat. No ale mi się tak pali taka lampka, że OK, to musimy teraz trzymać te wszystkie kontrakty, utrzymywać to, i taki tam kod, który tylko rośnie, rośnie, rośnie, rośnie. No więc jak jest z utrzymaniem event sourcingu? Co zrobić, żeby ten system oparty na event sourcing był utrzymywalny i czy takie popularne mity konferencyjne i mówienie, ooo będzie wszystko fajnie, super i nie martw się o nic - na ile to jest: włożyć sobie do szuflady i nie - a na ile jest tak, że faktycznie tak jest.

Oskar Dudycz: Wydaje mi się, że tak… Trudność wersjonowania event sourcingu istnieje, ale według mnie stopień skomplikowania i to - zwykle jak zaczynamy jakieś warsztaty czy spotkanie z ludźmi to jest zawsze, o, jak wersjonować zdarzenia i ok, jeżeli się tego nie robiło i się nie myślało o tym od początku, tylko się potem właśnie budzi z ręką w nocniku dwa lata później, no to to będzie trudne, tego się nie da zrobić łatwo, ale to też dotyczy każdej innej migracji, którą gdzieś musimy danych zrobić, jak się obudzimy się z ręką w nocniku po dwóch latach, że nie dbaliśmy o ten nasz model danych. No i faktycznie tych technik modelowania i opisu jak to robić poprawnie niestety materiałów nieco brakuje. Ale jak to można zrobić? Mówi się, że w event sourcingu tych danych się nie traci i faktycznie tych danych się nie traci, bo zapisujemy każde zdarzenie osobno i tak dalej. Ale to wcale nie znaczy, że my te dane wszystkie musimy trzymać w jednym miejscu. Bo jeżeli wyodrębnimy sobie takie cykle życia, nawet jak mówiłem o tej kasie w Biedronce, to do takiej bieżącej operacyjnej działalności konkretnej kasy interesuje nas tylko to, co się wydarzyło w ramach tej zmiany w tej kasie, prawda?

Oskar Dudycz: Czyli wszystkie te pozostałe dane albo już są w ogóle nam niepotrzebne do transakcyjnej takiej operacyjności, czyli do podejmowania decyzji biznesowych? A może są potrzebne tylko gdzieś do modeli odczytu? A może w ogóle jedyne do czego nam są potrzebne, to do jakiegoś audytu itd. Więc w przypadku event sourcingu, tak samo jak w przypadku innych rodzajów przechowywania danych, powinniśmy rozróżniać temperaturę naszych danych, czyli te gorące dane, które są na bieżąco. Używamy ich cały czas, je tam zmieniamy, chłodne, czyli których w ogóle nie potrzebujemy, lub takie letnie, które trochę potrzebujemy, trochę nie. No więc nic nie stoi na przeszkodzie, żeby te zdarzenia, których nie potrzebujemy, przenieść gdzieś indziej. Czyli przykładowo jak mamy dane audytowe, to przenieść je do jakiegoś bloba. Jeżeli mamy dane, potrzebujemy tylko do analityki, to może przenieśmy je do jakiegoś systemu analitycznego i z tego event stora je usuńmy potem. Czyli powinniśmy stosować techniki archiwizacji. No i w event sourcingu kluczowe jest myślenie o cyklu życia obiektów. To jest jedna z charakterystyk, bo im dłużej on żyje, tym strumień jest dłuższy i tym trudniej się pracuje.

Oskar Dudycz: Jeszcze co do samego wersjonowania - jeżeli byśmy zastosowali te techniki archiwizacji to zobacz, że jeżeli mamy nową wersję zdarzenia i wiemy, że w naszym systemie obiekty żyją powiedzmy nie wiem, tydzień-dwa, to moglibyśmy wdrożyć wersję, która wspiera i starą i nową. Miną dwa tygodnie czy tam trzy dla bezpieczeństwa i wiemy, że już nie przeżył żaden obiekt w praktyce, który jest w starej wersji, więc możemy zacząć ją po prostu… Od niej odchodzić, nawet pomimo, że gdzieś może te dane w teorii mogłyby być, ale w praktyce ich nigdy nie będzie, bo już je zarchiwizowaliśmy.

Szymon Warda: Ale z ciekawości - trochę Ciebie zchallenge’uję - jak mamy dostęp księgowy czy księgowość… Faktycznie, może, te dane - czy mogą żyć dłuższy czas de facto, czy możemy tylko sięgnąć do np. faktury sprzed 2-3 lat? No nie? Czy w tym momencie faktycznie trzymasz tę wersję zdarzeń? De facto wersjonujesz, czy jednak migrujesz te zdarzenia na nowsze schematy. Jak tutaj to wypośrodkować?

Oskar Dudycz: Ja raczej wersjonuję, czyli przez wersjonowanie mogę w ogóle nie wersjonować. Jeżeli jedyne do czego się spodziewam to do audytu, to wystarczy, że będę w stanie to odczytać. Potem. Jeśli mam dane w JSONie, to można w ogóle zignorować te wersje, których nie będziemy używać. Co do innych - to są różne taktyki, bo możemy trzymać te wersje i ich nie używać, ale żebyśmy byli w stanie w jakiś to obsłużyć. Jest też technika tak zwany app casting, czyli trzymamy w kodzie tylko aktualną wersję plus takie funkcje, które biorą stary payload i w locie go… Gdy deserializujemy to zamieniają na nowy format, dzięki czemu co prawda mamy te zdarzenia w różnych wersjach, ale w kodzie już jesteśmy w stanie używać tylko tej najnowszej. Z kolei Greg Young twierdzi, że przy każdym wdrożeniu nowej wersji systemu powinniśmy przepisywać wszystkie te zdarzenia na nowy format i archiwizować te, których nie używamy. Z tym, że ja nigdy tak nie zrobiłem. Tzn. robiłem tego typu przepisywania, ale to raczej przy jakiejś… Jak robiłem jakąś migrację danych. Raczej nie przy okazji konkretnego deploymentu. Bo żeby takie rzeczy robić to trzeba mieć naprawdę opanowane te narzędzia i tak jak mówiłem te narzędzia jeśli chodzi o takie tematy DevOpsowe.

Oskar Dudycz: Żeby to zrobić płynnie, no to trzeba je dobrze znać. One nie dostarczają tak z out of the box tego typu rzeczy, więc tutaj trzeba bardzo uważać.

Szymon Warda: To zalecenie Grega brzmi jak utrudnianie sobie bardzo mocno deploymentu. To brzmi jak duży proces budowania aplikacji. Mi też się tak trochę pali żółta lampeczka, że trochę nie za bardzo to brzmi.

Oskar Dudycz: To znaczy miałoby to sens, jeżeli by to robić konsekwentnie, bo z jednej strony pozbywamy się tych starych danych, których nie używamy i wtedy ten zakres bieżących danych jest względnie mały stosunkowo, no ale wiemy jak to w praktyce jest. No niestety realia są takie, że większość ludzi w ogóle nawet nie myśli w tych kategoriach, które dane potrzebują, które nie, a co dopiero żeby je gdzieś archiwizować itd. Tak to praktyka wygląda.

Szymon Warda: I selling point jest taki, że nie wiesz, których danych masz potrzebować za ileś tam lat.

Oskar Dudycz: No tak.

Szymon Warda: Dlatego się wtedy brało wszystko zdarzenia, więc okej, ciekawe podejście.

Oskar Dudycz: Znaczy wiesz, te dane ciągle masz, bo równie dobrze możesz je przenieść na jakiś taki…

Szymon Warda: Archiwum.

Oskar Dudycz: Archiwum albo w ogóle do innego klastra, który jeżeli tych danych nie potrzebujesz, czyli np. do odbudowy czy gdzieś, to nie musisz za niego płacić tyle co za normalny produkcyjny. Jak przychodzi Ci sytuacja, gdy tych danych zaczynasz znowu potrzebować, podkręcasz suwaczek i jest to też tańsze, więc jest to dosyć faktycznie rzecz, która jest trochę zaprzeczeniem tego selling pointu. No ale ja też na przykład nie używam w zachwalaniu tego że audyt itd. OK. W ogóle według mnie event sourcing sam w sobie, on nie ma takiej pojedynczej killer feature, że można powiedzieć to jest to. I tu powinieneś używać event sourcingu. Raczej to jest zestaw tych różnych rzeczy, które on daje, po prostu out of the box i tak jakby skumulujemy te wszystkie rzeczy. To on daje wtedy tak jakby ten… Lub może dać, przechylić decyzję na korzyść użycia event sourcing. Ale jeżeli byśmy wzięli każdą z tych rzeczy osobno, no to moglibyśmy łatwo to zbić, że ok, w tym innym narzędziu też to mamy.

Łukasz Kałużny: Słuchaj, to kolejne pytanie do tego, które też jest mitem konferencyjnym, blogowym. Od tego się przejawia, że jak robisz event sourcing to jest wymagane. Musisz omodelować i projektować aplikacje zgodnie z DDD Domain Driven Design. Musisz koniecznie użyć CQRSa, inaczej to się rozsypie jak domek z kart. I jest taki mit, że musimy te wszystkie… Określam to mitem, bo się z tym nie zgadzam. Właśnie, że musimy to wszystko zawsze pakować w kupie. Jakie jest Twoje doświadczenie?

Oskar Dudycz: Prawda leży gdzieś po środku. Tutaj jeżeli ktoś tak twierdzi, to w ogóle powinniśmy się zapytać go co ma na myśli przez DDD. Ja sam nie wiem jak bym określił DDD. Dla mnie Domain Driven Design to jest po prostu jakiś taki przybornik, zestaw różnych narzędzi skupionych na biznesie, które mogę lub nie, ale nie muszę używać w swoim projekcie. No i faktycznie event sourcing. Tak jak wspominałem im lepiej modelujemy dane tym będzie nam łatwiej również technicznie, więc pod tym kątem skupienia na biznesie jest dużo wspólnego z Domain Driven Design. Z tym, że ja osobiście coraz więcej widzę, że Domain Driven Design. Użycie takie książkowe w przypadku event sourcingu dodaje więcej ciężkości tego event sourcingu niż zalet choćby agregaty, choćby… Ogólnie te wzorce te taktyczne są bardziej takie ciężkawe, object-oriented, gdzie event sourcing jest dosyć prostym wzorcem, bardziej takim funkcyjnym. Więc te wzorce taktyczne można jak najbardziej używać z event sourcingiem… Ale ja bym od razu najpierw się zastanowił czy faktycznie musimy - i to uprościć. Jak najbardziej. Więc to co ma wspólnego event sourcing z DDD to na pewno skupienie na biznesie.

Oskar Dudycz: No ale wiadomo, społeczność DDD też wszystkie rzeczy skupione na biznesie zawłaszcza. Ja się czasem śmieję, że co, 16 lat temu nikt nie próbował robić aplikacji skupionych na biznesie? Nagle dopiero od 15 lat ktoś pomyślał, że kurczę, fajnie by było, żeby te aplikacje robiły to co biznes chce? No chyba to tak nie do końca jest. Nawet Eric Evans… On zresztą jest bardzo skromną osobą i on też mówi, że po prostu skatalogował te wzorce, więc.

Szymon Warda: Nie wzięło się znikąd na pewno.

Oskar Dudycz: Dokładnie. Co do CQRSa, to CQRS… Też zależy jak ludzie to definiują. Jeżeli tak jak na konferencjach to zupełnie nie potrzeba używać CQRSa do event sourcing. Jeśli tak, jak oryginalna definicja, czyli że segregujemy nasze operacje na zapisy i odczyty i dodatkowo każdą z tych operacji skupiamy się na tym, żeby robiła coś biznesowo konkretnego, czyli zmieniła, powiedzmy wykonała jakąś logikę biznesową albo zrobiła… odpytała pod jakimś kątem biznesowym nasze dane - to zdecydowanie event sourcing… Potrzebuje tego. No bo żeby zapisać takie biznesowe, sensowne zdarzenie, to musimy znać biznesową intencję. No bo jeżeli mamy zapytanie z API typu create, update, delete to w najlepszym razie nam wyjdzie CRUD sourcing, a nie event sourcing, bo będziemy mieć zdarzenia created updated deleted. No spoko, tylko technicznie może i można byłoby to nazwać event sourcingiem, ale nie da to nam żadnych zalet event sourcingu, tego typu podejścia. Więc ja też mówię, że CQRS, event sourcing to jest tak jak tequila, limonka i sól dobrze ze sobą grają, ale to nie jest tak, że to musi wszystko być razem.

Oskar Dudycz: No event sourcing bez CQRSa takiego… Powiedzmy, no mówię tego prostego wzorca segregacji zachowań. To trudno by było zrobić. A CQRS bez event sourcingu? Jak najbardziej, polecam, Oskar Dudycz.

Szymon Warda: A pytanko takie, no bo poruszyłeś temat CRUDów. Z reguły właśnie, jak mamy jakiśtam projekt to jakieś tam CRUDy zaczynają się itd. I z reguły też mało wiemy o tej domenie, mało wiemy co potrzebujemy. Teraz… Jakie jest Twoje go-to podejście tak naprawdę, czy albo może co uważasz i w jakich sytuacjach? Czy powinniśmy zaczynać od event sourcingu jak widzimy, że okej, tu może pasować, czy jednak wejść w prosty model załóżmy relacyjny albo jakiś inny sposób i dopiero stwierdzić ok, tu by nam pasował event sourcing. Jak już znamy lepiej domenę, wiemy co wiemy, czego potrzebujemy i w tym momencie przymigrować na event sourcing.

Oskar Dudycz: Nawet właśnie ostatnio w sobotę miałem takie dyskusje na warsztatach na ten temat. Nie ma dobrej odpowiedzi na ten temat, no bo z jednej strony faktycznie gdy uczymy się domeny i gdy zaczynamy greenfield no to tak, nie znamy technologii najprawdopodobniej, które używamy, bo skoro zaczynamy greenfield, to się chcemy wyszaleć i wybieramy jakieś nowe technologie, albo chcemy jak to ładnie się mówi po prostu być innowacyjni. No i najgorszą rzeczą, którą możemy zrobić, to uczyć się i technologii i domeny. Więc jeżeli nie mamy kogoś, kto robił coś w event sourcingu, to faktycznie może to nie być najlepszym pomysłem, żeby powiedzmy rozpoczynać wszystkie możliwe bitwy w jednym czasie. Z tym, że wiemy, że jak czegoś nie zaczniemy robić od razu, to po pierwsze pewnie już do tego nigdy nie wrócimy. Po drugie jeżeli się uczymy czegoś nowego, to jak na pewno wiecie, to jest proces. Musimy popełnić ileś tam błędów, musimy się tego nauczyć. To nie jest tak, że nagle powiemy o. To jest mój moment, teraz będziemy to robić w event sourcingu, to tak to nie zadziała.

Oskar Dudycz: I tak tą krzywą nauki będziemy musieli przejść. No więc tutaj jest kluczowe, jak bardzo to nam pasuje do naszego projektu, jak bardzo ważnym elementem tego traktujemy. No bo jeżeli wiemy, że tutaj ten event sourcing nam da dużą przewagę konkurencyjną i jest to coś, co… Na czym chcemy się oprzeć z jakichś powodów, no to lepiej zacząć to wcześniej robić. Dodatkowo w przypadku greenfielda zaletą według mnie event sourcingu jest to, że jak pracujemy w event sourcingu to te zdarzenia są bardzo fajną formą dokumentacji danych. I nawet jeżeli nasze zrozumienie tego będzie powodowało, że będziemy mieć kilka wersji tych zdarzeń, no to z drugiej strony w greenfieldzie dokumentacji raczej nie uświadczysz. Więc te zdarzenia mogą być taką formą też dokumentacji historycznej jak nasze zrozumienie i nasza domena się zmieniała. Czy to jest warte czy nie? Trudno mi powiedzieć. To zależy od konkretnego projektu, ale niektórzy właśnie twierdzą, że nie, w greenfieldach nigdy event sourcing. Ja może też podeślę Wam… Jest taki fajny artykuł Aleksieja Zimarewa. Moglibyśmy dodać do materiałów właśnie po odcinku gdzie on fajnie to właśnie w ten sposób opisuje.

Oskar Dudycz: Z tym, że jeszcze tylko jedną rzecz i ja bym raczej zalecał, żebyśmy się nie rzucali na kluczową domenę z event sourcingiem, bo tam stopień skomplikowania jest tak duży, że tak jak powiedziałeś… Zanim zrozumiemy tą domenę to dużo popełnimy błędów. Więc jeżeli kompletnie nie znamy event sourcingu, nikt w naszym zespole nie zna. Zacznijmy od czegoś małego. Wdrożymy tą małą rzecz na produkcję. Popełnijmy te błędy na takiej sytuacji, gdzie nikt nam głowy za to nie urwie, gdzie sami się nie spalimy ze wstydu. Nawet jak nam się to nie uda. Coś co moglibyśmy spokojnie wyrzucić do śmietnika i nikt by nam tutaj problemu z tego nie robił.

Szymon Warda: Mi się super podobała jedna rzecz, co powiedziałeś, że używać tam gdzie event sourcing byłby naszą przewagą konkurencyjną. I to jest bardzo dobre podsumowanie de facto. Czyli nie, że fajnie byłoby użyć, tylko że jeżeli użyjemy, to będą super, super zyski z tego na poziomie nawet biznesowym. Tak naprawdę. To bardzo, bardzo dobre podsumowanie.

Łukasz Kałużny: Dobra, Oskar, będziemy powoli kończyć i gdybyś powiedział o trzech takich rzeczach najważniejszych, których chciałbyś, żeby ludzie z tej rozmowy zapamiętali, zapamiętali o event sourcingu.

Oskar Dudycz: To pierwsza rzecz, zmarnuje od razu, to event sourcing na Kafce. Nie, nie róbcie tego. Użyjcie narzędzi, które są do tego dedykowane. Druga sprawa, pobawcie się trochę event sourcingiem. Niekoniecznie od razu na produkcji, bo event sourcing jest wzorcem, który może dać przewagi tam… Jeżeli macie procesy, które są nieco bardziej skomplikowane, gdy potrzebujecie wiedzieć co się wydarzyło i mieć taką lepszą diagnostykę czy wkład pod analitykę. No i uważam, że właśnie to nie jest tak, że musimy go używać wszędzie, ale warto go mieć w swoim przyborniku, bo im więcej mamy rzeczy właśnie w przyborniku takim programistycznym, liderskim, Patoarchitekckim, no to tym lepiej, tym lepsze będziemy mogli podjąć decyzje, gdy nawet… Jeżeli teraz tego w naszym projekcie nie potrzebujemy, no to jeżeli się zdarzy taki moment, to chociaż będziemy w stanie wiedzieć i będziemy w stanie to wykorzystać. Chyba jeszcze mi została jedna rzecz - no to przede wszystkim event sourcing też jest czymś, co może jest ciągle niszą, ale mocno się według mnie rozwija. Nawet InfoQ w swoim raporcie to potwierdza. Nieco zbyt optymistycznym, ale jest to też coś, co faktycznie w świecie tym takim rozproszonym, w świecie, gdy storage jest tani, ale informacje są bezcenne, może nam dać pewne zalety i warto chociaż spróbować, bo nie jest taki straszny, jak go malują.

Szymon Warda: No dobrze, to w takim razie powoli zbieramy się. To powiedz gdzie szukać, gdzie szukać materiałów? Jak, co robić, żeby wiedzieć więcej?

Oskar Dudycz: Zachęcam do lektury mojego bloga event-driven.io

Szymon Warda: Zachęcamy.

Oskar Dudycz: Staram się tam takie pigułki konkretne przekazywać jak właśnie… Nie tylko event sourcingu, ale takie moje przemyślenia. Najwięcej jest o event sourcingu, czyli jak rozwiązywać konkretne problemy pragmatycznie. Myślę, że warto sobie też na YouTubie poszukać choćby wiadomo, rzeczy Grega Younga. Też Greg pracuje nad nową książką, jest już bliski ukończeniu. Mnie można też znaleźć w Architecture Weekly. Prowadzę taki newsletter. Są też tam webinary, gdzie czasem coś o event sourcingu przekazuję. A jeśli chodzi ogólnie o event sourcing, to też na blogu eventstore.db się sporo pojawia. Polecam z narzędzi właśnie Marten, Event Store DB, Axon. W zależności od tego w jakiej technologii pracujemy, warto się tym pobawić. No i przede wszystkim, no, myslę, najlepiej spróbować i się przekonać samemu. Czy to faktycznie jest takie trudne i straszne.

Szymon Warda: Dobrze.

Łukasz Kałużny: To Oskar, dziękujemy za dzisiaj i podzielenie się wiedzą.

Szymon Warda: Za bardzo praktyczną rozmowę.

Oskar Dudycz: Dziękuję Wam bardzo, bardzo się cieszę. Dzięki, mam odhaczony kolejny element, wystąpiłem w moim… Jednym z moich ulubionych podcastów, także cieszę się bardzo. Słucham każdy odcinek.

Łukasz Kałużny: Dzięki, wzajemnie. Na razie.

Oskar Dudycz: Dzięki.

Łukasz Kałużny: Trzymajcie się.