CQRS mówi między innymi, że commandy nie powinny niczego zwracać. Jak do tego podchodzicie? Myślę, że takim typowym przypadkiem kiedy jednak chcielibyśmy coś zwracać z commands jest sytuacja kiedy chcemy uniknąć sterowania wyjątkami i zamiast nimi rzucać mamy zamodelowane dobre i złe wyniki za pomocą klas i wtedy commandy/ command handlery zwracałyby jakiegoś Eithera<BadResult,GoodResult). O ile bad resulty nie stanowią jakiegoś problemu to pojawia się pytanie czym te good resulty powinny być, bo co powinno się zwrócić jeśli commenda zmieniła np. hasło użytkownika? Jego ID? UserName? Może to nowe hasło a może po prostu krótką informację typu "Operation successful"?
0
4
Sampeteq napisał(a):
CQRS mówi między innymi, że commandy nie powinny niczego zwracać.
A jak zwrócą to coś się stanie? Ja np zwracam i mam gdzieś co mówi teoria. Jak dodaje nowy zasób to zwracam po dodaniu w odopowiedzi wszystko dane wraz z wygenerowanym ID, po aby nie trzeba było np pobierać danych. Ale też nie zawsze to robię. Jeśli jest np zmiana hasła to wystarczy Ok bez body bo i po co.
2
https://vladikk.com/2017/03/20/tackling-complexity-in-cqrs/
Without violating any principles, a command can safely return the following data:
Execution result - success / failure;
Error messages or validation errors, in case of a failure;
The aggregate’s new version number, in case of success;
Najpierw odpowiedz sobie na pytanie jaki problem próbujesz rozwiązać stosując CQRS, dużo większym problemem niż zwracanie danych przez Command, jest zmiana stanu aplikacji przez Query. Query powinno się dawać powtarzać bez konsekwencji (np przez błąd sieciowy). Na pewno nie należy robić czegoś w stylu GetOrCreate.
ID najlepiej generować client side, jeśli będziemy się trzymać pełnego puryzmu (poza zwracaniem błędów jw) i rezultat z jednego Command nie musimy używać jako parametru do kolejnych to możemy na przykład stworzyć aplikację w pełni działającą client side, kolejkować commandy i zwyczajnie je wysłać po przywróceniu połączenia z siecią. Jeśli commandy są od siebie zależne to sprawa się komplikuje i wymaga dodatkowej (czasem dość skomplikowanej) logiki, dlatego na przykład zwracanie ID z serwera to nienajlepszy pomysł.
W przypadku HTTP i REST w ogóle nie możliwe jest nie zwrócenie rezultatu. Zawsze idzie jakiś kod zwrotny
0
Sampeteq napisał(a):
CQRS mówi między innymi, że commandy nie powinny niczego zwracać.
Dlaczego?
Sampeteq napisał(a):
O ile bad resulty nie stanowią jakiegoś problemu to pojawia się pytanie czym te good resulty powinny być, bo co powinno się zwrócić jeśli commenda zmieniła np. hasło użytkownika?
W warstwie domeny może to być nawet obiekt domenowy usera, którego ten update dotyczył, na UI to może sam status http poleciec w zależności czy operacja się powiodła czy nie
1
Podchodzę do tego pragmatycznie, i jeśli w przypadku jakiejś konkretnej aplikacji zwracanie wartości ma sens to robię to. Zakładam że pisząc o zwracaniu wartości mówimy o czymś innym niż zwykły wynik wykonanej operacji. Bo to że coś takiego można zwrócić to chyba oczywiste? Ewentualnie jeśli komuś będzie lepiej na serduszku to może rozróżniać między commands a requests, co czasem się stosuje. I to w zasadzie tyle, nie ma co się nadmiernie rozdrabniać nad jakimiś dogmatami. Fajnie to opisał Greg Young w jednej prezentacji, piszę z telefonu więc nie mogę wstawić linku z konkretnym czasem, więc oglądać od 22:45.