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.
Jakoś tak, jeśli chodzi o komunikację backend-frontend, to zawsze myślimy i gdzieś jest to przyjęte już, Powinniśmy myśleć o tym, że rozmawiamy pomiędzy zespołami, jakie powinno być API takie, żeby było wygodne, czy mamy back and frontends, czy mamy API first, jakie mamy podejście. Tak tutaj zdarzeniami jakoś te takie praktyki myślenia i zarządzania danymi nie są popularne. Dokumentowanie tego API też nie jest popularne. Po co? Skoro to nie jest API, to po co to dokumentować? Kod jest najlepszą dokumentacją, spójrz sobie. Dokładnie. Tylko najpierw znajdzie się repozytorium, w którym ten event jest definiowany. Tak, no według mnie jednym z takich, już odchodząc z takich ogólnych żartów,
Nie zawsze tak jest, ale bardzo często. Jeszcze co do samego takiego właśnie, jak sobie radzić z tymi zależnościami, no to wrócę do tego, co mówiłem na początku, czyli tego znanego podziału Frontend Backend, czyli API First i Backend for Frontends. To bardzo fajnym narzędziem jest tutaj do rozróżniania jak się komunikować kontekst mapy, czyli jeżeli sobie wyznaczymy jaka jest relacja między modułami, jest nam też łatwiej uwzględnić tą formę komunikacji, bo jeżeli na przykład mamy Moduł zamówienia, który jest takim centralnym koordynatorem, który gdzieś tam zbiera informacje, czy też o dostawie, o płatności itd., ale jednak jest bardziej takim, może nie koordynatorem, bardziej integratorem, czyli on tak jakby zbiera te informacje.
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.