Zasadniczo próbuję owinąć głowę koncepcją CQRS i powiązanymi koncepcjami.
Chociaż CQRS niekoniecznie obejmuje przesyłanie wiadomości i pozyskiwanie zdarzeń, wydaje się być dobrą kombinacją (co można zobaczyć w wielu przykładach / postach na blogu łączących te pojęcia)
Biorąc pod uwagę przypadek użycia dla zmiany stanu czegoś (powiedzmy, aby zaktualizować Pytanie na temat SO), czy uważasz, że następujący przepływ jest poprawny (jak w najlepszej praktyce)?
System wydaje zagregowaną komendę UpdateQuestionCommand, która może być podzielona na kilka mniejszych poleceń: UpdateQuestion, która jest skierowana na Root Aggregate Root, i UpdateUserAction (zliczanie punktów itp.) Na Root Aggregate użytkownika. Są one wysyłane asynchronicznie przy użyciu wiadomości typu punkt-punkt.
Zagregowane korzenie robią swoje, a jeśli wszystko pójdzie dobrze, odpalają odpowiednio odpowiednio EventUpdated i UserActionUpdated, które zawierają stan zlecony do sklepu z wydarzeniami. Aby zachować je w Yadayada, żeby być kompletnym, nie o to tutaj chodzi.
Te zdarzenia są również umieszczane w kolejce pub / sub do emisji. Każdy subskrybent (w tym prawdopodobnie jeden lub kilka Projektorów tworzących Widoki odczytu) może subskrybować te wydarzenia.
Ogólne pytanie: czy rzeczywiście najlepszą praktyką jest, aby polecenia były przekazywane punkt-punkt (tj .: odbiornik jest znany), podczas gdy zdarzenia są nadawane (tj. Odbiornik (odbiorcy) są nieznani)?
Zakładając powyższe, jaka byłaby zaleta / wada umożliwienia nadawania Komend za pośrednictwem pub / sub zamiast punkt-punkt?
Na przykład: Podczas nadawania poleceń podczas korzystania z Sagi może być problem, ponieważ rola mediacji, jaką Saga musi odgrywać w przypadku awarii jednego z zagregowanych korzeni, jest utrudniona, ponieważ saga nie wie, które zagregowane korzenie uczestniczą na początku .
Z drugiej strony widzę zalety (elastyczność), gdy wydawanie poleceń byłoby dozwolone.
źródło
Odpowiedzi:
Oświadczenie: Stawiam tylko pierwsze kroki w świecie CQRS, ale mogę zaoferować moje bieżące zrozumienie sprawy i zobaczymy, czy inni to potwierdzą. Wszystko, co piszę poniżej, ma motyw przewodni „jak widzę” i nie jest autorytatywne.
Przypadek 80%
Aby odpowiedzieć na twoje pytanie, polecenia są w rzeczy samej relacją punkt-punkt. Gdy polecenie wchodzi do kontrolera (aplikacji internetowej MVC), kontroler ten następnie prosi dyspozytora poleceń o znalezienie jednego i tylko jednego odpowiedniego modułu obsługi poleceń i deleguje pracę do tego modułu obsługi.
Dlaczego nie opublikować?
To kwestia odpowiedzialności . Jeśli coś wysyła polecenie, wiąże się ono z oczekiwaniem , że się spełni. Jeśli po prostu opublikujesz i masz nadzieję, że coś gdzieś to podejmie i zacznie działać , nie ma gwarancji, że tak się stanie. Poprzez ekstrapolację nie wiesz również, czy wielu procedur obsługi nie decyduje się na wykonanie polecenia, co może skutkować wielokrotnym zastosowaniem tej samej zmiany.
Z drugiej strony wydarzenia mają charakter informacyjny i uzasadnione jest oczekiwanie, że zero, dwa lub więcej elementów będzie zainteresowanych konkretnym wydarzeniem. Naprawdę nie dbamy o to, aby wprowadzić żądaną zmianę.
Przykład
Można to porównać do prawdziwego życia. Jeśli masz troje dzieci, wejdź do pokoju i po prostu wykrzycz „Posprzątaj łazienkę”, nie masz gwarancji, że ktoś to zrobi, i nieszczęśliwie, jeśli nie zrobi się tego dwukrotnie (jeśli masz posłuszne dzieci ;-) Powinieneś lepiej, jeśli przydzielisz określone dziecko do robienia tego, co chcesz.
Kiedy to dziecko kończy pracę, wygodnie jest krzyczeć „łazienka została wyczyszczona”, aby każdy, kto chce umyć zęby, wie, że może to zrobić.
źródło
When a command enters a controller (MVC webapp)
-? Czy korzystasz z usługi RESTful? lub niektóre hybrydowe punkty końcowe API? Czy możesz podać przykładexample.com/api/Post/AddPostComment
.Zgadzam się, że system inicjujący ogólnie nie spodziewałby się, że polecenie zostanie zrealizowane przez wiele systemów docelowych:
acknowledgement
i zakończone powodzeniemcompletion
lubfailure
mogą zostać opublikowane przez docelowy system w celu poinformowania inicjującego system).Jednak nadal warto zasubskrybować dodatkowych (nietransakcyjnych i zwykle „rozwiązłych”) konsumentów, którzy „podsłuchują” polecenia wydawane między systemami
źródło