Czy 1 rodzaj eventu powinien być obsługiwany przez wiele handlerów w razie potrzeb? Czy może tylko przez 1 handler, a w niższej warstwie powinien być rozdzielany do odpowiednich serwisów w zależności od potrzeb? Jakie jest zalecane podejście? Może są jakieś opracowane wzorce na ten temat?
0
2
Jak najbardziej może. To jedna z głównych zalet takiej architektury. Pozwala to osiągnąć open/closed principle na poziomie architektonicznym, gdzie nowa funkcjonalność może być łatwo dodwana poprzez "podpinanie" jej w formie handlera reagującego na jakiś istniejący event.
Aby osiągnąć taką formę obsługiwania eventów, stosuje się podejście pub-sub w brokerach.
0
Jasne, że tak. Wyobraź sobie, że masz np. event, który sygnalizuje koniec pierwszej fazy przetwarzania pliku. Wtedy jeden handler powinien zasygnalizować to na widoku, drugi zacząć drugą fazę przetwarzania pliku itp.
2
Może być obługiwany jak chcesz, reguł nie ma. Nie napisałeś o jaki poziom architektury ci chodzi, jakieś zdarzenia latające po aplikacji z UI, czy wiadomości pomiędzy mikroserwisami, ale właściwie bez różnicy:
Masz aplikację mobilną, aplikacja żąda jakichś danych z backendu, nie dostaje, klient http generuje event "brak sieci", a wszystkie komponenty UI, które są tym zainteresowane zmieniają kolor na czerwony.
W systemie z uS masz np. usługę, która generuje obrazki, serwisy, które mają zostać powiadomione o tym, że coś nowego się pojawiło i mają zrobić wersję png - pierwszy, który dostanie powiadomienie robi konwersję i konsumuje wiadomość, reszta nie musi, czyli typowa kolejka.
Ale z drugiej strony masz np. informację, że jakiś czujnik wykrył gdzieś włamanie leci on do topic'a i usługi odpowiedzialne za powiadomienie ochrony, właściciela muszą to odebrać i obsłużyć, bez przejmowania się tym co robi reszta.