101. Property Sourcing - EDA /Anti/Patterns
Rozpoczynamy nową mini-serię, w której bierzemy na warsztat konkretne problemy ze świata Event-Driven Architecture. Razem z Oskarem Dudyczem, autorem bloga eventdriven.io postanowiliśmy przejść przez listę "antywzorców", które sprawiają, że zamiast elastycznych systemów, fundujemy sobie architektoniczną drogę przez mękę. Na pierwszy ogień idzie temat Property Sourcing. W tym odcinku rozmawiamy z Oskarem m.in. o tym: dlaczego interfejsy w stylu Jiry i edycja każdego pola z osobna potrafią zepsuć architekturę jak Property Sourcing prowadzi do Event Bombardment i dlaczego twoje read modele mogą tego nie udźwignąć czym różni się zdarzenie małe od zdarzenia "mniejszego niż powinno być" jak wyjść z tej sytuacji obronną ręką, stosując translatory kontraktów i odpowiednie grupowanie danych
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
Ż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ć.
Dobrze, że miałem to nagrane, bo jakby ten kod, który zobaczyłem na swoich konsultacjach, na szczęście podobno nie był inspirowany moją, to mógłbym zostać posądzony na złamanie NDA, bo dokładnie tak to wygląda i w wielu organizacjach w ten sposób to działa, no i jeszcze zwiększa ten efekt skali, tak jak mówisz. Właśnie takie sourcowanie każdej zmiany, nawet eventu modułu, to jeszcze może doprowadzić z automatu do kolejnego problemu, tzw. event bombardmentu, gdzie twoje jakieś komponenty, twoje hendlery są po prostu obstrzeliwane jakimiś tam zmianami. Teraz wyobraź sobie sytuację, w której jest jakiś proces batchowy, który musi coś tam pozmieniać, bo jest jakiś importowany CSV z jakiegoś innego modułu, czy klient coś tam wrzuca i nagle tych zmian faktycznie trzeba przeprowadzić sporo. Nagle się okazuje, że przeprocesowanie prostej batchowej
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.
Jeżeli sobie nie zdajemy z tego sprawy, to jest ten najgorszy coupling w zasadzie. No to jeszcze możemy w sumie na koniec odesłać do książki Wladyka, Balancing Coupling in Software. Książka, która chyba w ogóle ostatnio robi trochę furory. Tak, wiem ile Wladik się nad nią męczył, więc bardzo się cieszę, że mu się udało ją skończyć. Czyli tak podsumowując, jeżeli zauważył w moim systemie faktycznie masę zdarzeń, ta proporcja się zmieniła, ta właściwość została zmodyfikowana, mam masę eventów typu updated, rename itd., to może to być sygnał, właśnie cierpię z tego dokładnie powodu, I być może tutaj pierwszym pomysłem powinno być wrócenie do tej deski kreślanskiej i zastanowienie się, co to znaczy biznesowo. Ja jeszcze dodam, że to jest też powiązane z wersjonowaniem kontraktów, ale ludziom się wydaje, że
Pokazano wszystkie 5 dopasowań. Transkrypcja generowana automatycznie i niesprawdzana ręcznie — może zawierać błędy.
Kliknij, aby znaleźć fragmenty, w których pada.
Rozpoczynamy nową mini-serię, w której bierzemy na warsztat konkretne problemy ze świata Event-Driven Architecture. Razem z Oskarem Dudyczem, autorem bloga eventdriven.io postanowiliśmy przejść przez listę "antywzorców", które sprawiają, że zamiast elastycznych systemów, fundujemy sobie architektoniczną drogę przez mękę. Na pierwszy ogień idzie temat Property Sourcing.
W tym odcinku rozmawiamy z Oskarem m.in. o tym:
dlaczego interfejsy w stylu Jiry i edycja każdego pola z osobna potrafią zepsuć architekturę jak Property Sourcing prowadzi do Event Bombardment i dlaczego twoje read modele mogą tego nie udźwignąć czym różni się zdarzenie małe od zdarzenia "mniejszego niż powinno być" jak wyjść z tej sytuacji obronną ręką, stosując translatory kontraktów i odpowiednie grupowanie danych