Schemat architektury event-driven: producenci zdarzeń publikują komunikaty, które trafiają do kanału i są rozsyłane do subskrybentów.
Dzięki temu producenci nie muszą znać konsumentów, mogą po prostu "odbić" zdarzenie do wspólnego kanału, a każde zainteresowane urządzenie lub usługa odbierze je osobno. Zdarzenia w takiej architekturze dostarczane są niemal w czasie rzeczywistym, a producenci i konsumenci są od siebie odseparowani. Każdy konsument (subskrybent) może samodzielnie zdecydować, które zdarzenia obsłuży.
Zalety architektury zdarzeń
Architektura event-driven ma wiele zalet, zwłaszcza w nowoczesnych, rozproszonych systemach:
• Luźne powiązanie komponentów: Producenci zdarzeń nie muszą znać detali implementacji konsumentów. Wystarczy, że wysyłają komunikaty do wspólnego kanału (brokera), a różne usługi nasłuchujące tego kanału odbiorą je niezależnie. Dzięki temu możemy łatwo dodawać nowe moduły (np. kolejne mikroserwisy) bez modyfikacji istniejących.
• Asynchroniczność i wydajność: Zdarzenia są przetwarzane niezależnie w tle, producenci od razu zwracają odpowiedź lub kontynuują pracę, a konsumenci obsługują je w swoim tempie. Pozwala to obsłużyć duży ruch (np. tysiące zdarzeń na sekundę) bez blokowania aplikacji.
• Skalowalność: W razie potrzeby możemy uruchomić wiele instancji usługi nasłuchującej na zdarzenia. Każda otrzymuje własny strumień do przetworzenia, co ułatwia poziome skalowanie i równoległe przetwarzanie.
• Odporność i niezawodność: Jeśli usługa-konsument chwilowo nie działa, zdarzenia mogą być przechowywane (np. w kolejce) aż do ponownego uruchomienia. Wiele brokerów (jak Azure Service Bus czy RabbitMQ) oferuje mechanizmy kolejek i logów, aby zapobiec utracie danych.
• Łatwa integracja: Różne systemy (nawet w różnych technologiach) mogą wymieniać się zdarzeniami przez wspólne kanały. Dzięki temu np. aplikacja ASP.NET Core może emitować zdarzenie, a serwisy Pythonowe czy Node.js mogą je odczytać i zareagować, bez sztywnego wiązania w kodzie.
Wdrażanie event-driven w .NET (ASP.NET Core)
W ekosystemie .NET dostępnych jest wiele sposobów na implementację architektury zdarzeń:
• Wbudowane zdarzenia C# (.NET Events): Klasy .NET oferują mechanizm event i delegate, np. public event EventHandler MyEvent;. To najprostszy sposób komunikacji między komponentami w ramach jednej aplikacji (procesu). Pozwala emitować zdarzenia i dodawać subskrybentów/metody obsługi.
• Mediator/Notifications (MediatR): Biblioteki takie jak MediatR wprowadzają wzorzec mediator, gdzie definiuje się zdarzenia domenowe (np. INotification lub własny IMyEvent), a następnie handlery wykonują logikę po ich publikacji. Dzięki wstrzykiwaniu zależności (DI) w ASP.NET Core możesz publikować zdarzenia wewnątrz kodu aplikacji bez bezpośredniego wywoływania metod innych klas.
• Broker wiadomości (Message Broker): W przypadku rozproszonych systemów (mikroserwisów) używa się zewnętrznych brokerów komunikatów. Popularne rozwiązania to Azure Service Bus, Azure Event Hubs, Azure Event Grid, RabbitMQ, Apache Kafka itp. Narzędzia takie jak MassTransit czy NServiceBus zapewniają gotową integrację .NET z tymi brokerami i realizują model publish-subscribe. Microsoft zaleca korzystanie z gotowych usług (np. Service Bus, Event Hubs, Event Grid) do obsługi komunikatów między usługami.
• Chmura i serverless: Na platformie Azure zdarzeniami można też sterować za pomocą usług serverless. Przykładowo Azure Functions może reagować na zdarzenie umieszczone w kolejce czy w Event Grid. Dzięki temu można łatwo budować funkcje, które zostają wyzwolone w momencie pojawienia się nowego zdarzenia (np. wpisu w kolejce czy pliku w magazynie).
Przykład typowego scenariusza event-driven: sklep internetowy.
Po przyjęciu nowego zamówienia moduł obsługi zamówień publikuje zdarzenie OrderCreatedEvent (z danymi zamówienia). Broker wiadomości przekazuje to zdarzenie do zainteresowanych usług: magazyn otrzymuje komunikat i rezerwuje towar, serwis faktur – generuje fakturę, serwis powiadomień – wysyła e-mail potwierdzający. Każda z tych usług pracuje asynchronicznie, nie blokując procesów zamówienia i obsługuje zdarzenie na własnych warunkach. Dzięki takiemu podejściu aplikacja staje się bardzo elastyczna: nowe reakcje na zdarzenie (np. księgowość, analityka) można dołożyć bez ingerencji w kod modułu zamówień.
Podsumowanie
Architektura event-driven to skuteczny sposób na budowanie elastycznych, składowalnych aplikacji działających w czasie rzeczywistym. Umożliwia luźne powiązanie komponentów i asynchroniczne reagowanie na zdarzenia, co przekłada się na lepszą wydajność i łatwiejsze rozwijanie systemu. W .NET i ASP.NET Core mamy do dyspozycji różne narzędzia, od prostych zdarzeń C#, przez wzorce mediator, aż po rozbudowane brokery wiadomości, dzięki którym łatwo zbudować system oparty na zdarzeniach. Jeśli chcesz zgłębić temat ASP.NET Core i nauczyć się tworzyć zaawansowane aplikacje (MVC i Web API), zachęcam do szkolenia online Szkoła ASP.NET Core. Znajdziesz tam praktyczne wskazówki dotyczące projektowania rozbudowanych systemów, w tym tych opartych na event-driven architecture.
