Najlepszy wykład o CQRS jaki do tej pory widziałem i w sumie jedyny, który w zrozumiały sposób nakreśla ten temat w odniesieniu do architektury aplikacji, a nie tylko modelowania domeny.
10:58. a ja zwracam w command result, bo jak sie dowiedziec, czy command sie wykonalo? Walic wyjatkami? Jak barbarzyńca? A moze nie mogla sie wykonac, bo np. dodalibysmy te sama osobe z tym samym imieniem i nazwiskiem i moze to ta sam? dedykowany result o tym informuje i nastepny command z flaga force wymusza dodanie. Wywalanie wyjatku byloby brzydkie, przeciez to nie jest awaria i to nie jest wyjatek tylko cecha logiki biznesowej.
a gdzie walidacja? na jakim poziomie mamy to robic i jak zwracac blad skoro command tylko wysyła żadanie i konczy na tym swoja prace? dajmy na to robie command do tworzenia produkt uw bazie, okazuje się, że nie przeszedł walidacji bo ma w nazwie niedozwolony znak czy cokolwiek. Jak to zaimplementować?
@@twitchy9948 ale jak zwraca odpowiedz jak command nie ma odpowiedzi? Kolejny wyjatek? Chore. Ja w swoim CQRS zwracam result przeslany z handlera lub warstw koncowych. A wywalanie wyjatkou zawsze mozna zrobic wstrzykujac do konstruktora klienta proxy sendera requestow, ktory jak dostanie negatywny result to wywali wyjatek i zapisze do loga.
mozesz validowac dto ( i tak pewnie to robisz w UI). Ja z UI biore smiecowe dto, waliduje i jak nie jest ok, mam strumien bledow i zaznaczam w UI kontrolki z blednymi wartosciami.
Command zawsze musi coś zwrócić. Nie można zrobić tak i nie przyswajajcie takiej techniki, że command to tylko command on musi mieć jakis , to jest jedyne poprawne podejście aby nie walić wyjątkami na każdym kroku.
Najlepszy wykład o CQRS jaki do tej pory widziałem i w sumie jedyny, który w zrozumiały sposób nakreśla ten temat w odniesieniu do architektury aplikacji, a nie tylko modelowania domeny.
10:58. a ja zwracam w command result, bo jak sie dowiedziec, czy command sie wykonalo? Walic wyjatkami? Jak barbarzyńca? A moze nie mogla sie wykonac, bo np. dodalibysmy te sama osobe z tym samym imieniem i nazwiskiem i moze to ta sam? dedykowany result o tym informuje i nastepny command z flaga force wymusza dodanie.
Wywalanie wyjatku byloby brzydkie, przeciez to nie jest awaria i to nie jest wyjatek tylko cecha logiki biznesowej.
To jest jak najbardziej poprawne podejście.
a gdzie walidacja? na jakim poziomie mamy to robic i jak zwracac blad skoro command tylko wysyła żadanie i konczy na tym swoja prace? dajmy na to robie command do tworzenia produkt uw bazie, okazuje się, że nie przeszedł walidacji bo ma w nazwie niedozwolony znak czy cokolwiek. Jak to zaimplementować?
rzucasz wyjątkiem, jakis middleware go przechwytuje i zwraca odpowiedz
@@twitchy9948 ale jak zwraca odpowiedz jak command nie ma odpowiedzi? Kolejny wyjatek? Chore. Ja w swoim CQRS zwracam result przeslany z handlera lub warstw koncowych. A wywalanie wyjatkou zawsze mozna zrobic wstrzykujac do konstruktora klienta proxy sendera requestow, ktory jak dostanie negatywny result to wywali wyjatek i zapisze do loga.
mozesz validowac dto ( i tak pewnie to robisz w UI). Ja z UI biore smiecowe dto, waliduje i jak nie jest ok, mam strumien bledow i zaznaczam w UI kontrolki z blednymi wartosciami.
Command zawsze musi coś zwrócić. Nie można zrobić tak i nie przyswajajcie takiej techniki, że command to tylko command on musi mieć jakis , to jest jedyne poprawne podejście aby nie walić wyjątkami na każdym kroku.
"Żadnych frameworków. CQRS jest zbyt prosty żeby istniały frameworki"
Niestety nie jest to już prawdą :(