Czy agregaty powinny być narzędziami obsługi zdarzeń
Po przestudiowaniu wielu materiałów i przykładów zaczynam właśnie pierwszą prawdziwą próbę systemu DDD/CQRS/ES.
1) widziałem przykłady pozyskiwania zdarzeń, gdzie Agregaty są manipulatorami zdarzeń, a ich Metoda obsługi dla każdego zdarzenia jest tym, co mutuje stan na instancji obiektu (implementują interfejs IHandleEvent
2) widziałem też przykłady, w których Agregaty wyglądałyby jak zwykłe klasyczne Klasy encji modelujące domenę. Inna klasa obsługi zdarzeń jest zaangażowana w mutację stanu.
State, oczywiście, jest mutowany na agregacie przez procedury obsługi zdarzeń w obu przypadkach podczas przebudowy agregatu z wywołania repozytorium, które pobiera wszystkie poprzednie zdarzenia dla tego agregatu, oraz gdy obsługa poleceń wywołuje metody na agregacie. Chociaż w tym ostatnim widziałem przykłady, gdzie zdarzenia są publikowane w obsłudze polecenia, a nie przez agregat, który jestem / align = "left" /
Moje pytanie brzmi Jakie są plusy i minusy między metodą (1) A (2)
2 answers
Zadanie odbierania / obsługi polecenia różni się od jego działania. Podejście, które przyjmuję, to mieć opiekuna. Jego zadaniem jest otrzymanie polecenia. Polecenie Przechowuje identyfikator AggregateId, którego może następnie użyć, aby uzyskać wszystkie zdarzenia dla agregatu. Następnie może zastosować te zdarzenia do agregatu za pomocą metody LoadFromHistory. To aktualizuje agregat i sprawia, że jest gotowy do otrzymania polecenia. Więc moja skrócona wersja to opcja 2.
Mam kilka postów, które uważasz za pomocne, pierwszy to przegląd przepływu typowej aplikacji CQRS / ES. Nie jest tak, jak powinno być, tylko jak często są. Możesz to znaleźć na CQRS – przewodnik krok po kroku po przepływie typowej aplikacji !
Mam również post na temat budowania zagregowanego korzenia dla CQRS i ES, jeśli to pomocne. Możesz to znaleźć w Agregat korzeń – jak zbudować jeden dla CQRS i Event Sourcing
W każdym razie, mam nadzieję, że to pomoże. Wszystkiego najlepszego w budowaniu aplikacji CQRS / ES!
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2014-11-15 14:16:11
Chociaż zgadzam się z Codescribler , muszę pójść nieco dalej w szczegóły. ES polega na wyrażeniu stanu encji jako strumienia zdarzeń (które będą przechowywane). Obsługa wiadomości jest tylko implementacją usługi, która powie jednostce, co ma robić.
Z ES Jednostka implementuje swoje zmiany, generując jedno lub więcej zdarzeń, a następnie stosując je do siebie. Encja nie wie, że jej zmiany pochodzą z polecenia lub obsługi zdarzenia (powinno to być 'zawsze' a obsługa poleceń, ale dobrze.. czasami nie ma to znaczenia), jednak modyfikuje stan poprzez własne zdarzenia, które zostaną opublikowane przez usługę (lub sam magazyn zdarzeń).
Ale... w niedawnej aplikacji, z pragmatycznych powodów moja jednostka ES akceptowała polecenia bezpośrednio, chociaż sama jednostka nie była implementacją obsługi poleceń. Opiekun przekaże polecenie jednostce.
Tak więc możesz obsługiwać wiadomości bezpośrednio z podmiotem, ale tylko jako szczegóŠ'y implementacji, nie zalecaĺ' bym wyznaczania encji do obsĹ 'ugi poleceĺ " /zdarzeĺ", poniewaĹź jest to naruszenie rozdzielenia problemĂłw.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2014-11-15 17:57:31