Czy CQRS nadaje sie do aplikacji innych niz crudy?

Moze trochę przewrotny temat, ale chciałbym poznać troche CQRS i zrobić aplikacje do kalkulacji np zakupów w sklepie.
W bazie danych mam np produkty dosępne w sklepie.
Czy stosując CQRS da sie coś takiego zrobić? Bo we wszystkich kursach Commmandy i Query odnoszą się do zadań na bazie. Jak użyc tego w takim kalkulatorze? Aplikacja ma umożliwiać wybór produktu oraz określenie jego parametrów, dodanie tego do koszyka. W grę wchodzi też sprawdzenie przed dodaniem do koszyka czy podane parametry produktu są prawidłowe, albo gdy wybrany zostanie produkt X który musi być sprzedawany zawsze w zestawie z produktem Y, to do koszyka powinny trafić obydwa produkty. Jak tutaj zaprząc CQRS, co będzie Commandami i Query?

Nie tylko się nadaje, ale wręcz czym bardziej skomplikowana aplikacja tym bardziej CQRS może się przydać. Wydaje mi się natomiast że próbujesz chwytać się złego narzędzia. Masz wymagania na procesy które są bardziej złożone niż operacje CRUD, w związku z czym zainteresuj się np. task-based UI. Tutaj również fajny filmik w temacie.

@Aventus: dzięki zapoznam sie z tymi materiałami. Tak te procesy sa bardziej zaawansowane niz zwykly crud bo np chcialbym zeby np jak uzytkownik sklada sobie zestaw komputerowy to zeby aplikacja tez zliczyla jak mocny potrzebny zasilacz i tylko takie dala do wyboru.

tak a propos tematu
"CQRS" widzialem na poziomie serwisu, czyli serwis miał część (metody) C i Q
ale przy skalowaniu, dany serwis dalej ma część C i Q

czy ktos widział na żywo serwisy które są albo C albo Q, tak zeby skalować częśc albo C albo Q?

to mi się kojarzy z apką pogodową
jest milion pytających
a komendatnów jest paru 3 może 10, albo niech będzie jeden na kraj to koło 200

i teraz część serwisów jest Q - dla tych co pytają o pogodę i to jest 99,95% systemu
a 0,05 to serwisy C, gdzie komendanci wpisują dane

@Aventus: mam sytuacje ze chce na podstawie wybranych podzespołów komputerowych dobrać zasilacz. Czy do serwera powinienem wysłać Commanda z listą podszespołów i na serwrze przeliczyc zapotrzebowanie na moc na podstawie tych podzespołów? Tylko jak wtedy zwrócić przeliczona moc i np zasilacze spełniajace to kryterium?

Chyba ze to zle rozumiem? Bo chce ta aplikacje zrobić jako webapi. Czy Commandy i Query powinienem wykorzystać do komunikacji api z baza a uzytkownikowi wystawiac jakies gotowe metody oczekujace na liste podzespołów w parametrze i zwracające liste zasilaczy?

Najprościej jak to możliwe:
Commandem będzie dodanie/usunięcie procesora do/z koszyka
Query to odpytanie np o listę zasilaczy czy o sam koszyk

Standardowo command nie zwraca nic w przypadku gdy request jest poprawny. Natomiast query zwraca obiekty.
Na język restowy:
GET to query
POST/PUT/DELETE/PATCH to command

@mussel:

czy ktos widział na żywo serwisy które są albo C albo Q, tak zeby skalować częśc albo C albo Q?

Tak, pracowałem przy takim systemie. Serwis odpowiedzialny za Q służył zwracaniu zmaterializowanych widoków na potrzeby UI- wliczały się w to dosyć skomplikowane zapytania gdzie zwracało się widok danego stanu w konkretnym momencie w czasie. Nie wiem jak to dokładniej wytłumaczyć, ale kiedy np. wyświetlało się A, to dodatkowo wyświetlało się podzbiór informacji B, natomiast kiedy wyświetlało się B, to UI również wyświetlał podzbiór informacji A i B, w dodatku na podstawie obecnie wyświetlanej informacji pewne operacje były zablokowane lub też nie.

Widok ten był zagregowany, a więc był rezultatem działań w różnych serwisach. Co za tym idzie kiedy użytkownik klikał jakiś przycisk aby dokonać zmian, command był wysyłany do jednego z tych serwisów.

@kalimata boska_cebula dobrze prawi, chociaż od tego też są wyjątki. Bywają przypadki gdzie np. query musi być wysłane POSTem. I jeśli RESTowi puryści próbują po przeczytaniu tego podnieść wrzawę to sprawa jest prosta- bezpieczeństwo przede wszystkim. Czasem pewnych zapytań zwyczajnie nie można wysyłać przez URL, szczególnie w dobie RODO. Ogólnie w Twoim przypadku rozwiązań można znaleźć kilka- pierwsze co mi przychodzi na myśl to że można wysłać wybrane podzespoły jako commands, natomiast po wysłaniu tego klient oddzielnie może wysłać zapytanie o wymaganą moc zasilacza- wtedy logika obsługująca query może obliczyć wszystko w locie, zakładając że nie jest to zbyt skomplikowana i długotrwała operacja.

1. Czyli Query tu nie jest tylko odpytywaniem bazy i może w nim być każda dowolna logika? Tak wiec moge sobie jako parametr przekazywany z query podać liste elementow i w logice query przeliczyc jakie zasilacze sa potrzebne i je zwrocic tym samym query?

2. Jeszcze się zastanawiam na sytuacja ze mam webapi i z baza przeprowadzam operacje za pomoca CQRS. A co w przypadku gdy mam jakąś operacje do któej nie potrzebuje bazy, tylko np tak dal uproszeczenia załóżmy ze jest sytuacja ze user podaje liczbe i ja chce sprawdzic czy jest ona parzysta i zwrócić true jeśli parzysta i false jeśli nieparzysta. Czy to jest Query z parametrem w postaci liczby podanej przez użytkownika?

@kalimata:

Czyli Query tu nie jest tylko odpytywaniem bazy i może w nim być każda dowolna logika?

Nie do końca. Logika obsługująca zwracany wynik? Tak. Logika modyfikucjąca stan aplikacji? Nie.

Tak wiec moge sobie jako parametr przekazywany z query podać liste elementow i w logice query przeliczyc jakie zasilacze sa potrzebne i je zwrocic tym samym query?

Tak, chociaż ja bym zrobił to prościej. W query podał bym ID koszyka.

1. Jeszcze się zastanawiam na sytuacja ze mam webapi i z baza przeprowadzam operacje za pomoca CQRS. A co w przypadku gdy mam jakąś operacje do któej nie potrzebuje bazy, tylko np tak dal uproszeczenia załóżmy ze jest sytuacja ze user podaje liczbe i ja chce sprawdzic czy jest ona parzysta i zwrócić true jeśli parzysta i false jeśli nieparzysta. Czy to jest Query z parametrem w postaci liczby podanej przez użytkownika?

To nie ma nic wspólnego z CQRS. W CQRS z samej tego natury mamy do czynienia z modyfikowaniem stanu aplikacji (command) i zwracaniem tego stanu (query).

Aventus napisał(a):

To nie ma nic wspólnego z CQRS. W CQRS z samej tego natury mamy do czynienia z modyfikowaniem stanu aplikacji (command) i zwracaniem tego stanu (query).

Czyli to chodzi o mogdyfikowanie/zwracanie modelu, a jak chce sobie jakieś obliczenia zrobić to i tak robie to poza CQRS i ewentualnie wynik obliczen przekazuje do commanda/query?

No nie. Po prostu Twoje query może przed zwróceniem modelu wykonać jakieś manipulacje na nim (np. obliczenie mocy procesora). Prawdpodobnie błędnie zakładasz że model który zwraca query musi być tym samym co model tworzony/aktualizowany przy wykonywaniu command. W rzeczywistości te modele mogą się różnić. Jak wcześniej wspomniałem model zwracany w query może być np. zagregowanym widokiem wynikającym z operacji w różnych częściach systemu.

W Twoim przypadku możesz np. wysłać query GetRequiredPowerSupplyPower przekazując ID koszyka. Logika obsługująca query załaduje podzespoły z koszyka (np. wyciągnie je z bazy danych) i obliczy wymagane zapotrzebowanie. Mode zwrócony z query do klienta może wtedy po prostu wyglądać tak:

{
  "requiredPower": 550
}

W tym przypadku nie ma mowy o modifykowaniu jakiegoś instniejącego modelu- Ty tworzysz nowy model zwracany do klienta, ale jest to model widoku tworzony w locie. Nic nie jest zapisywane do bazy danych. Na podobnej zasadzie mógłbyś użyć view w SQL, a więc za pomocą SQL dokonywałbyś tego obliczenia. Wtedy Twój kod obsługujący query po prostu zwraca przygotowany widok ładując go z bazy.

@Aventus: dziękuję, teraz mi się bardziej rozjaśniło.
A mógłbyś mi jeszcze powiedzieć, czy jesli chce uzyc CQRS to muszę stosować też DDD i EventSourcing? Bo nie chce uzywac DDD i ES.

Nie musisz. CQRS to coś całkowicie innego niż DDD jak i ES. Te wszystkie zagadnienia się dobrze uzupełniają ale żadne nie jest wymagane do tego aby używać drugiego.