101. Property Sourcing - EDA /Anti/Patterns

Produkcja Polskie Towarzystwo Astronomiczne Better Software Design to podcast o projektowaniu oprogramowania. Wraz z moimi gośćmi rozmawiamy o architekturze, szczegółach implementacyjnych i wyzwaniach z tym związanych. Jeśli interesujesz się tworzeniem oprogramowania, to ten podcast jest właśnie dla Ciebie. Zapraszam na odcinek. Cześć, Oskar. Cześć. Słuchaj, mam taki pomysł, aby w podcaście pojawiła się taka miniseria, no zobaczymy, czy będzie mini, bo temat, który chciałbym zaatakować, chyba taki mini nie jest, ale żebyśmy tak w każdym odcinku, tutaj będzie troszeczkę krótszy, wzięli na tapet jakiś konkretny problem ze świata eventowego.

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

Jeżeli będziemy mieli kilka modeli odczytu, a zwykle Jeżeli używamy architektury opartą na zdarzeniach, to między innymi po to to robimy, czyli no nawet zmiana powiedzmy imienia. No to możliwe, że mamy model odczytu, który widzimy tam w rogu, który pokazuje kto jest zalogowany, że mamy model odczytu, gdzie jest lista użytkowników, że mamy dane do faktury. Tych miejsc jest naprawdę bardzo dużo. O tym możemy sobie na początku nie zdawać sprawy. No wiesz, taki nawet prosty przykład. Tutaj kiedyś w rozmowie z Piotkiem przybyłem, jak rozmawialiśmy właśnie o pewnych, powiedzmy, antypaternach w ogóle w programowaniu, gdzie pojawił się ten przykład, który Piotrek pokazuje na konferencjach z adresem, jako jest trudność w zamodelowaniu struktury adresu i jaką on ma zmienność. I tak pomyślę sobie, że na obsługę zmiany takiego adresu bym potrzebował pewnie z sześciu, siedmiu eventów, a później pewnie jeszcze w aplikacji ten adres jest użyty w iluś tam miejscach, to przemnożone razy liczbę zmian, liczbę eventów, liczbę hendlerów, które ten event muszą obsługiwać.

Że w zespole bardzo nagle szybko spadła chęć utrzymywania tego kodu. I wiesz, było takie pytanie, no kurczę, dlaczego? Przecież to jest kod najnowszy w organizacji. Tu są fajne wzorce, no jakby chcieliśmy je mieć, to co tu nie zagrało? Powodem było oczywiście to, o czym wspomniałeś. Wprowadzenie prostej modyfikacji, nagle się okazuje, że musisz się przekopać przez 8 warstw. Od samego requestu HTTP, przez te kontrolery, przez formularze, przez eventy, przez handlery, przez git modele. Na koniec końców się okazało, że ktoś właśnie sourcował kruda w ten sposób. Tak, szczególnie jak ktoś sobie jeszcze połączy to wszystko, tak jak mówisz, z tymi stoma warstwami, czyli to, co mówiliśmy o Clean Architecture, co się trochę pastwiłem nad tym. Ale w wielu miejscach ja naprawdę to widziałem. Co gorsza, niedawno miałem takie konsultacje, gdzie na The Voxie miałem takie wystąpienie, gdzie właśnie o tych warstwach i właśnie tej liczbie zmian, które trzeba dokonać.

I te urządzenia IoT też są w stanie generować miliony zdarzeń. To nie jest nic nadzwyczajnego dla nich. Tylko, że tak naprawdę też zmiana takiej temperatury nie jest żadnym dla biznesu informacją, chyba że przeskoczy jakiś tam próg graniczny. Jakiś alarm na przykład się odpali, wynikające z tego konsekwencje. Tak, ale to znowu ten alarm się nie odpala na tych żywych danych, tylko bo ktoś przeanalizował w jakimś interwale czasowym i tak dalej. Więc ja bardzo często też sugeruję, podobnie jak w przypadku tej takiej edycji, Czyli najpierw zgrupujmy sobie te sygnały. To nie są w zasadzie zdarzenia w takiej nomenklaturze tworzenia aplikacji. Zwykle, gdy mówimy zdarzenia, myślimy zdarzenie biznesowe. Powiedzmy w każdym razie w tej nomenklaturze architektur opartych na zdarzeniach.

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.

To tak samo powinniśmy myśleć o naszych zdarzeniach, bo to nie jest też tak, że zdarzenia to są jakieś magiczne, to są ciągle wiadomości, które są wysyłane między kontrakt, tak jak powiedziałeś, który musimy zawrzeć. I jedną rzeczą, o której ludzie znowu często nie zdają sobie od razu sprawy, bo jest też bijane poza tym, że te zdarzenia powinny być jak najmniejsze, to że Architektury oparte na zdarzeniach, dzięki nimi dostajemy luźno powiązane komponenty, tylko że one są luźno powiązane z perspektywy producenta, bo producent opublikuje zdarzenie i on w teorii, zgodnie z zasadami, które gdzieś może są spisane, nie powinien się interesować, kto nas słuchuje.