104. Clickbait Events - EDA /Anti/Patterns
Kontynuujemy mini-serię o antywzorcach Event-Driven Architecture - ponownie z Oskarem Dudyczem. Tym razem jednak bierzemy na początek na warsztat puchnące zdarzenia: jedno “uniwersalne” zdarzenie, które próbuje zadowolić wszystkich naraz. Kolejne pole, kolejne ID “na wszelki wypadek”, aż w końcu wysyłamy w świat pół swojej bazy danych. Zupełnie jak w wierszyku o sznurku Jurka - ktoś dorzuci papierek, aż robi się góra śmieci. Jednak to tylko pretekst do tego, aby dotknąć właściwego tematu, czyli podziału między to, co publiczne, a to, co prywatne.
Już myślałem, że powiesz brutalnie CSV przez FTP. Też można. Też można. Ale nie no, realnie no, ja widziałem w tylu projektach i w tylu zespołach, gdzie ludzie po prostu siedzą i klepią te handlery i wyimaginowane scenariusze, gdzie jest jakiś race condition, bo te dane pochodzą z różnych modułów. No, gdzie jedyną ich potrzebą jest wyświetlenie tego gdzieś na widoku. I to nawet nie podjęcie decyzji, tylko wyświetlenie na widoku. Więc dla mnie to jest po prostu strata czasu, energii i tak dalej. Ale tak, no czasem jest to zasadne i faktycznie przepychanie przez wiadomości, szczególnie jeśli mamy na przykład Kafka, Kafka Connect, to są takie technologie, które są w stanie nam na przykład zsynchronizować dwie różne bazy danych.
To w teorii, dlaczego by nie można było zrobić tak, że mamy te swoje nasze wewnętrzne zdarzenia do obsługi zdarzenia, ale jeżeli na przykład używamy kafki, to zrobić dwa topiki zewnętrzne, czyli taki back-end for front-end, czyli w naszym przypadku, powiedzmy, topics for consumers, czyli wydzielić. To w Rabicie tak samo można zrobić, inną kolejkę. Chodzi o to, że dzielimy sobie, że tu publikujemy zdarzenia, czy też komendy, czy inne wiadomości związane z obsługą przesyłki, więc one nie mają np. informacji o płatności itd., tylko komendy zdarzenia, które służą do komunikacji obsługi wysyłki, a na drugim np. te związane z płatnością.
Pokazano wszystkie 2 dopasowania. Transkrypcja generowana automatycznie i niesprawdzana ręcznie — może zawierać błędy.
Podróżnicy opisują problem z event driven architecture, gdzie eventy stają się zbyt komplikowane i nieefektywne.
Rozmowa o problemach z eventami, takich jak dorzucanie dodatkowych informacji i użycie słowników.
Opis antywzorca Clickbait Event, gdzie zdarzenie zawiera niepełną informację, wymagając dodatkowego kliknięcia.
Rozmowa o klasyfikacji zdarzeń i zastosowaniu enrichment lub anti-corruption layer.
Analiza różnicy między zdarzeniami publicznymi a prywatnymi oraz propozycje rozwiązań.
Omówienie konceptów takich jak Context Map i propozycje modelowania komunikacji między modułami.
Ważność zastanowienia nad celami rozszerzania kontraktu lub wprowadzania nowych zdarzeń.
Rozdziały i streszczenia generowane automatycznie. Pełna transkrypcja nie jest publikowana — wyszukaj frazę, aby zobaczyć dopasowane fragmenty.
Kliknij, aby znaleźć fragmenty, w których pada.
Kontynuujemy mini-serię o antywzorcach Event-Driven Architecture - ponownie z Oskarem Dudyczem. Tym razem jednak bierzemy na początek na warsztat puchnące zdarzenia: jedno “uniwersalne” zdarzenie, które próbuje zadowolić wszystkich naraz. Kolejne pole, kolejne ID “na wszelki wypadek”, aż w końcu wysyłamy w świat pół swojej bazy danych.
Zupełnie jak w wierszyku o sznurku Jurka - ktoś dorzuci papierek, aż robi się góra śmieci. Jednak to tylko pretekst do tego, aby dotknąć właściwego tematu, czyli podziału między to, co publiczne, a to, co prywatne.