101. Property Sourcing - EDA /Anti/Patterns

Event-driven architecture, event-sourcing, wszystko, co się kryje dookoła właśnie świata zdarzeń. Wybrali sobie po każdym problemie, bo wiesz, jak to jest z problemami, nie? Przychodzą kopią i zazwyczaj na produkcji wtedy jest smutno. Tak, żeby ktoś, kto albo zaczyna, albo chciałby zacząć właśnie z architekturami, sterowanymi zdarzeniami, wiedział, gdzie nie warto wkładać rąk, bo po prostu poważy. Pewnie. Tematów jest dużo. Lista, którą gdzieś tam mam w myślach, to ona zasadniczo się dosyć długo scrolluje. Okazuje się, że tych problemów świata zdarzeniowego jest bardzo, bardzo dużo, a że ty prowadzisz bloga Event Driven IO, do którego oczywiście tutaj też będzie podlinkowanie, no to myślę, że jesteś właściwą osobą, żebyśmy o tych tematach porozmawiali. Czyli jestem problematyczną osobą.

Problem solverem. Także jeżeli w ogóle ktoś chciałby właśnie poznać świat eventów, to ja od razu odsyłam do bloga Oskara i do wszystkich rzeczy, które w Open Source robisz, bo to jest naprawdę coś, co warto zobaczyć. Dzięki. To co, zaczynamy? Jedziemy. Dobra. Property Sourcing. Kiedy cię uderzyło ostatnio? I co to w ogóle jest? No tak, no to ogólnie rzecz biorąc część tych antywzorców nazwa oczywiście pochodzi od przekręcania nazwy event sourcing, czyli wszystko to złe, co może dotyczyć. No to... W przypadku property sourcingu to możemy się domyślić, że chodzi o jakieś właściwości, czy też propercje, czy propertisy, jak to czasem ludzie mówią, zdarzeń.

Albo potwierdzony trochę, ale nie bardzo. To są takie rzeczywiste problemy. Każdy myślę, że tego typu sytuacje widział. I jeżeli my za każdym razem dodajemy tego typu informacje, to może się okazać, że... My musimy powiadomić wszystkie inne osoby. To nie musi być nawet temat międzyzespołowy, ale czasem, jeżeli mamy skomplikowany moduł, to zorientować się, kto na te wszystkie, w jaki sposób rzeczy powinien obsłużyć, to jest sporym wyzwaniem tak naprawdę. Właśnie chyba wydaje mi się, że doprowadzenie w projekcie do tego property sourcingu to jest takie otwarcie puszki Pandory kruchości projektu. Tak. Jakby cokolwiek zmienisz, to się może przełożyć właśnie na zmiany tych zdarzeń, a na tych zdarzeniach prawdopodobnie są zapięci jakieś konsumenci.

Może w swoim module, może w twojej aplikacji. A w najgorszym przypadku, jeżeli jeszcze wiesz, poszedłeś piętro dalej i zacząłeś te eventy świadomie, nieświadomie dzielić z innymi zespołami i poszło to w świat, no to nagle się okazuje, że prosta zmiana już nie jest taka prosta. Tak, to jest mniej więcej to, co Łukasz Szydło też w paru swoich prelekcjach fajnie o zdarzeniach pokazywał, że ogólnie w komunikacji takiej przez wiadomości, że zawsze powinniśmy brać pod uwagę to, Co wprowadzenie nowego typu zdarzenia, nowej funkcjonalności, jaki ma wpływ na zmianę w innych miejscach? I my powinniśmy nad tym się zastanawiać, bo property sourcing w momencie, gdy piszemy kod, to nie jest problem. No co najwyżej, no dobra, no musimy doklepać te ileś tych rzeczy, ale jak

Oskar Dudycz. Komponent, który nasuchuje na to, a potem kolejne komponenty, to nagle się okazuje, że może to zbąbelkować ekstremalnie. Kurczę, pytanie, czy to zawsze widać od razu na początku? Zwykle nie. Zwykle nie. I to jest takie złudnicze, bo na początku ten kącik jeszcze fajnie wygląda. Więc ja teraz pamiętam jeden z projektów, który miałem gdzieś tam okazję kiedyś otrzeć, który implementował właśnie event sourcing i okazało się bardzo, bardzo szybko, że po 3-4 miesiącach

Tak, no to może faktycznie pokażmy jakieś potencjalne rozwiązania tych problemów. I potem nieco szerzej, w jaki sposób na to patrzeć. Jeżeli zaczęlibyśmy od tego takiego kruda, bo najczęściej jak ktoś zaczyna pracować z event sourcingiem, to jeszcze nie ma tych mięśni wyćwiczonych myśleniem w kategoriach biznesowych. To jest coś, z tego co ja zauważyłem, zwykle przychodzi z czasem. Najpierw trzeba się przekopać przez ten przykład z balansem konta. Tak. Wiesz, doprowadzimy kiedyś do delegalizacji tego przykładu zaraz obok koszyka e-commerce'owego i może coś się zmieni. Ja już ten przykład u siebie z sampli usunąłem chyba, także nie ma już u mnie w sampli, ale na blogu jeszcze chyba można znaleźć, ale jest taki artykuł, który mówi, że już tego nie używam.

No to choćby zrobić takie zdarzenie, które mówi, OK, no było co było, to jest mój aktualne zrozumienie mojego procesu biznesowego i te dane, które uważam, że będą mi potrzebne w przyszłości. I w momencie, gdy nasłuchujemy, no to zależy, czy stosujemy event sourcing, czy ogólnie event driven. No bo jak event sourcing, no to pewnie musimy też to u siebie w logice biznesowej zmienić. I to jest nieco łatwiejsze. A jeżeli mamy takie typowe event driven, gdzie te są pełno innych miejsc w systemie, które nas słuchują na te zdarzenia, to oczywiście musimy powiedzieć temu komuś, że słuchaj, tu jest takie nowe zdarzenie. Jak ono przyjdzie, to znaczy, że musisz mu zaufać.

Famous last word. Ale tak na serio, no to... Ja w ogóle też proponuję bardzo często, że jak zaczynamy pracować z systemem, to zostawili sobie takie zdarzenie wytrych, typu to jest mój stan i tego się trzymajmy, jakby coś poszło nie tak. Ale w skrócie chodzi o takie podsumowanie tego, co mieliśmy do tej pory i mówimy, było co było, od teraz będziemy robić już to inaczej. Jeżeli mamy event sourcing i mamy bazę relacyjną, rzeczywiście możemy sobie zrobić migrację, prawda? Albo możemy sobie zrobić takie tak zwane skopiuj i transformuj, czyli zaciągamy te istniejące zdarzenia, transformujemy je w locie i zapisujemy do nowego strumienia, czy też do nowej kolejki, której będziemy wysyłać.

I są dwa takie najczęstsze problemy, które według mnie wtedy w ogóle trzeba się zastanowić, czy powinniśmy używać tej konkretnej sytuacji podejścia zdarzeniowego. Jedno to jest IoT, a drugie to jest edycja pliku np. jak mamy Google czy coś takiego. Historia zmian. Bo często jak doradzam osobom, to się mnie pytają, że właśnie robimy takie edytowanie, że tam ktoś może sobie jakiś tam draft dokumentu robić i potem może sobie robić cofanie tych zmian i tak dalej. I w sumie fajnie, bo to event sourcing, mamy audytowalność i tak dalej, tylko że tak naprawdę wtedy przy tych edycjach, jeżeli to jest jakaś edycja tekstu, no to tych zdarzeń to będzie tam tysiące, miliony pewnie, które nie niosą ze sobą żadnej, kompletnie żadnej wartości biznesowej.

Więc zgrupujmy sobie, zróbmy takie procesowanie wstępne tych danych i wyciągnijmy tę wartość biznesową, czyli tak jak mówisz. Alarm albo nie wiem, podejrzane zachowanie typu, ja miałem taki system, gdzie ktoś na bazie, w jaki sposób ktoś tam kupony zniżkowe w Burger Kingu czy w tego typu rzeczach sprawdzał, czy kasjerzy czegoś tam nie próbują kombinować, że sobie tam nie nazbierali sami. Więc to jest informacja biznesowa, a nie, że ktoś tam wbił coś czy Ale to jest bardzo podobny problem do Property Sourcingu. Troszkę inny, ale jak tytuloniłeś, bombardowanie zdarzeniami. Nie sądziłem, że wnioskiem z naszej pierwszej rozmowy o Property Sourcingu będzie problem.

W ogóle może EDA jest problemem. Wyzwaniem. Jako teraz słyszałeś, że jesteś menadżer, to powinieneś mówić wyzwanie. Ale tak, no też umówmy się, że pewnym problemem jest to, że te wzorce są w ogóle nadużywane. I tam, gdzie de facto nie ma potrzeby stosowania w ogóle takich konceptów, no to one, wiesz, z pełną pompą wchodzą na salony. Tak, ja uważam, że w ogóle największym problemem w architektury, opartym na zdarzeniach, jest to, że musimy myśleć i rozmawiać z innymi ludźmi. To jest straszny problem, naprawdę. Ale to jest takie, że szukamy sobie jakiegoś innego sposobu na wyjście z tej sytuacji, o której powiedzieliśmy tutaj, nie? Czyli mam projekt, którym jest używany property sourcing i to poszło w świat, I oprócz tej jeszcze, powiedzmy, tego etapu ustalenia tego kontaktu nowego zdarzenia, na który oczywiście ktoś musi się zapiąć, tak ściągam jakiegoś takiego, wiesz, półśrodka. Co mógłbym zrobić, żeby jeszcze może nie inwestować u mnie w bardzo głęboką przebudowę, ale już jednocześnie jakby naprawić ten inny świat, w sensie to, co jest na zewnątrz mojego modułu.