Czy powinienem użyć polecenia czy zdarzenia?

Różnica między poleceniem a wydarzeniem w komunikacji autobusowej wydaje mi się nieco niejasna. Wiem, że polecenia powinny być wykonywane tylko raz, podczas gdy zdarzenie może być obsługiwane wiele razy, ale nadal nie jestem pewien, kiedy użyć polecenia lub zdarzenia.

Spójrzmy na przykład:

Gdy nowy użytkownik rejestruje się w aplikacji internetowej, powinniśmy założyć mu konto i wysłać wiadomość e-mail z potwierdzeniem.

Tworzenie konta - wydaje się, że jest to właściwe miejsce do wysłania komunikatu CreateUserCommanddo magistrali i umożliwienia wyspecjalizowanemu komponentowi obsługi go.

A może nie powinno się tego nawet realizować przy asynchronicznej komunikacji magistrali? Chcemy, aby użytkownik mógł od razu zalogować się do aplikacji. W przypadku autobusu nie mamy gwarancji, kiedy polecenie zostanie wykonane.

Wysyłanie wiadomości e - mail - po utworzeniu konta przez komponent widzę 2 możliwości

Wyślij kolejne polecenie do magistrali SendConfirmationEmailCommand
Opublikuj wydarzenie UserAccountCreatedEvent

I pozwól komponentowi wysyłającemu e-maila złapać go i wykonać zadanie.

Z jednej strony chcę, aby wiadomość e-mail z potwierdzeniem została wysłana tylko raz (użyj polecenia), z drugiej strony uważam, że może być wiele elementów zainteresowanych nowo zarejestrowanymi użytkownikami. Rejestrator lub może nadawca SMS.

Jak byś to wdrożył?

event-programming cqrs service-bus

— Andrzej Gis
źródło

Zasadniczo polecenie opisuje żądanie, które ma zostać wykonane, natomiast zdarzenie opisuje coś, co się wydarzyło:

Polecenie wymaga wykonania pewnej akcji przez procesor, a ta czynność powinna być wykonana tylko raz przez ten procesor.
Zdarzenie to powiadomienie o pewnej akcji, która została już wykonana lub o zdarzeniu zewnętrznym. Kilku procesorów / agentów może być zainteresowanych uzyskaniem informacji o zdarzeniu. Kilka z nich może dodatkowo wydawać polecenia lub działania wymagane przez to powiadomienie w swojej dziedzinie odpowiedzialności.

W twoim scenariuszu rozumiem, że:

CreateUserCommand to polecenie
UserAccountCreatedEventto wydarzenie, które powinno zostać wydane po CreateUserCommandpomyślnym zakończeniu przez usługę zarządzania kontem

Teraz są dwie możliwości:

Usługa zarządzania kontem wydaje się SendConfirmationEmailCommandna magistrali, ponieważ oczekuje, że to polecenie zostanie wykonane przez bardziej wyspecjalizowaną usługę.
Usługa zarządzania kontem nie robi nic więcej niż wysłanie powiadomienia o zdarzeniu po zakończeniu i pozostawia innej usłudze (np. Usługi komunikacyjnej, subskrypcji itp.) Decyzję o tym, czy wysłać e-mail / sms / etc ... i czy konieczne do wydania SendConfirmationEmailCommandpolecenia do wykonania przez jakąś bramę.

Jeśli wybrałeś podejście oparte na magistrali usług, warto skorzystać z elastyczności, na jaką pozwala, tj. Faworyzować opcję 2.

— Christophe
źródło

Dzięki, to wszystko wyjaśnia. Dwa kolejne pytania dotyczące opcji 2: 1. Skąd usługa zarządzania kontem dowie się o wykonaniu polecenia? Wierzę, że dzieje się tak poprzez słuchanie wydarzeń publikowanych przez wyspecjalizowane służby po zakończeniu ich zadań - niż jaki jest prawdziwy cel usługi zarządzania kontem? Aby ponownie opublikować wydarzenia? Wydaje się zbędne. 2. Nie zrozumiałem także, kto powinien wystawić SendConfirmationEmailCommand. Usługa zarządzania kontem czy „inna usługa”?

— Andrzej Gis,

1) moje założenie było takie, że usługa zarządzania kontami wykonała zadanie i wysłała zdarzenie, gdy zakończyło się ono pomyślnie (tzn. Nie napotkało błędów). Ale masz rację: możliwe jest, że usługa zarządzania kontem wysyła sobie polecenia do usługi trwałości / bazy danych i musi monitorować zdarzenie zakończenia zadania (np. Odpowiedź asynchroniczną).

— Christophe

@gisek 2) w autobusie usługowym, wyobrażam sobie, że masz bardzo wyspecjalizowane usługi, z których każda ma ograniczoną odpowiedzialność. W takim przypadku zarządzanie kontem wykonuje tylko tworzenie i powiadamia każdego, kto jest zainteresowany, że zostało ono wykonane. Inne usługi monitorowałyby następnie reakcje. Na przykład możesz mieć menedżera ds. Komunikacji, który byłby odpowiedzialny za stosowanie reguł biznesowych do decydowania o tym, kiedy i jak przekazywać zdarzenia użytkownikom. Jeśli wykonasz 1) +2) w tej samej usłudze, nie potrzebujesz magistrali usług.

— Christophe