Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: CQRS czyli co....

Coraz częściej spotykam się z wzorcem (tekstami o nim) CQRS (Command Query Responsibility Segregation).

Wzorzec bardzo przydatny ale "bije" w tradycyjne systemy relacyjne z normalizowanymi bazami transakcyjnymi, dlaczego? Najpierw tu opis:

http://martinfowler.com/bliki/CQRS.html

a teraz coś robię i nie tylko ja od pewnego czasu:
1. system pracowicie kolekcjonuje pojedyncze zapisy o sprzedaży
2. system pracowicie mieli tysiące danych analizując dane o sprzedaży

czujecie? zapisujemy pojedyncze zdarzenia a mielimy ich ogromne kolekcje, czy "sprzedawca" i "analityk" to te same byty w dziedzinie?

Nie koniecznie, jeżeli w modelu dziedziny "odkryjemy", że inaczej postrzega "świat" fakturzysta a inaczej "analityk" to w skali macro mamy system ERP i system BI/Hurtownia, pierwszy kolekcjonuje dane drugi je "wyciąga".

No i mamy CQRS od ładnych paru lat, czemu o tym teraz piszę? Bo warto taki wzór podziału stosować w skali micro w projektach... czyli w modelu dziedziny.

a Wasze zdanie o CQRS? Dlaczego napisałem, że "bije w bazy relacyjne"? Bo modelu dziedziny NIE NORMALIZUJEMY, bazę danych projektujemy "pod model dziedziny" a nie "pod model relacyjny" całości systemu..... Jarek Żeliński edytował(a) ten post dnia 27.03.12 o godzinie 08:24
Aleksander Olszewski

Aleksander Olszewski Kierownik Projektów
IT, PRINCE2
Practitioner

Temat: CQRS czyli co....

Jarek Żeliński:
...
a Wasze zdanie o CQRS? Dlaczego napisałem, że "bije w bazy relacyjne"? Bo modelu dziedziny NIE NORMALIZUJEMY, bazę danych projektujemy "pod model dziedziny" a nie "pod model relacyjny" całości systemu.....

Jak na razie, po przeczytaniu kilku artykułów w sieci mam dziwne wrażenie, że:
1. Jest to powrót do architektury typu Klient-Serwer, gdzie na serwerze mamy miks aplikacyjno-bazodanowy, zapisujący tak naprawdę stany obiektów.
2. Same dane są nierozerwalnie powiązane z warstwą aplikacji i wymiana samej warstwy aplikacji może być mocno problematyczna.
3. Komunikacja z np. Hurtownią Danych może się odbywać tylko poprzez tą samą aplikację, co te dane tworzy.
4. Wątpliwość moją budzi problem z wydajnością w aplikacjach wysokowydajnych, takich jak serwisy internetowe w wysoką liczbą żądań na minutę.
5. Brak normalizacji automatycznie oznacza wysoką redundancję danych, co sprzyja utracie spójności danych i ich jednoznaczności, co może z czasem spowodować bardzo kosztowną akcję migracyjną lub faworyzowanie hurtowni, jako jedynego wiarygodnego źródła informacji (chociaż rola hurtowni jest inna).

To tak po krótce minusy. Wątpliwość moją budzi w ogóle wybór RDBMS do utrwalenia stanu obiektów (bo chyba z grubsza do tego wszystko się sprowadza). Bez relacji zapytania do RDBMS są równie wydajne jak odczyt z dysków, a przy dyskach SSD być może nawet bardziej wydajne. W połączniu z XML mamy zgodność technologii obiektowych (wszak XML operuje pojęciami obiektowymi). Jeśli komuś XML nie pasuje, może być YAML czy JASON czy cokolwiek innego.
Paweł Grzegorz Kwiatkowski

Paweł Grzegorz Kwiatkowski Architekt
oprogramowania,
Ericsson

Temat: CQRS czyli co....

Dla mnie CQRS ma rację bytu w skali mikro (rozumianej jako kontekst pojedynczego systemu). W skali makro można doszukiwać się analogii do CQRS (na tej samej zasadzie co astrofizyka vs. świat atomu),
ale trzeba patrzeć w skali makro, czyli nie przez wzorce projektowe, a przez wzorce architektoniczne.

Temat: CQRS czyli co....

CQRS jako wzorzec nie mówi nic o bazach danych, w tym w szczególności nie mówi nic o relacyjnych bazach danych.

CQRS zakłada, że system posiada dwa modele: jeden służący do przetwarzania transakcji, a drugi do odpytywania o ich wyniki.

Jeśli chodzi o kwestie implementacyjne (bazy danych etc.) to część C(ommand) czyli model do przetwarzania transakcji _powinien_ być znormalizowany, podczas gdy część (Q)uery, czyli model do odczytu raczej nie.

W przypadku CQRS ciężko mówić o jednym modelu dziedziny, ale jeśli już, to zwykle jest to synonim modelu C(ommand)
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: CQRS czyli co....

a czy nie raz nie jest tak (to pewne uproszczenie), że tam gdzie mamy Command (bieżące jednostkowe transakcje) używamy wzorca Active record a tak gdzie Query, wzorca Active table?

Wydaje mi się, że sens tego jest taki, że "te same" dane raz postrzegamy "detalicznie" a raz "grupowo"?

(przytaczam diagram Fowlera):

Obrazek


w dziedzinie mamy zarówno model pojedynczych faktów i bytów i model operujący na kolekcjach (model dziedziny zawiera zarówno obiekt Fakturę jak i obiekt znający "dane o sprzedaży")Jarek Żeliński edytował(a) ten post dnia 27.03.12 o godzinie 23:35
Wojciech Soczyński

Wojciech Soczyński Programista
eksplorator -
blog.wsoczynski.pl

Temat: CQRS czyli co....

Jarek Żeliński:
a czy nie raz nie jest tak (to pewne uproszczenie), że tam gdzie mamy Command (bieżące jednostkowe transakcje) używamy wzorca Active record a tak gdzie Query, wzorca Active table?

Wydaje mi się, że sens tego jest taki, że "te same" dane raz postrzegamy "detalicznie" a raz "grupowo"?

(przytaczam diagram Fowlera):

Obrazek


w dziedzinie mamy zarówno model pojedynczych faktów i bytów i model operujący na kolekcjach (model dziedziny zawiera zarówno obiekt Fakturę jak i obiekt znający "dane o sprzedaży")
Wydaje mi się, że wzorce Active Record czy Active Table nic nie mają wspólnego CQRS - tzn. pewnie mogą być wykorzystane jako pewna implementacja dostępu do storage'u.

konto usunięte

Temat: CQRS czyli co....

a Wasze zdanie o CQRS?

http://codebetter.com/gregyoung/2010/02/16/cqrs-task-b...

CQRS to tak na prawdę bardzo prosty design pattern polegający na rozdzieleniu interfejsu serwisu na dwa w którym:
- pierwszy zawiera metody do realizacji przypadków użycia (metody które zmieniają stan systemu) - drugi zawiera metody do pobierania danych

Według mnie pomysł jest ... zły. Z dwóch powodów.

- wymusza na programiście / projektancie umieszczanie w serwisie logiki związanej z widokiem.
- nie ma żadnych konkretnych zalet poza potencjalnym poprawieniem wydajności (umieszczanie serwisów na odrębnych maszynach).

Uważam, że CQRS jest próbą ominięcia brzydkiej architektury (bałagan po stronie View spowodowany 'niekompatybilnością' DataModel Serwisu i View) poprzez przenoszenie i formalizowanie (nadanie nazwy, napisanie książki) bałaganu do serwisu (QueryModel / CommandModel).

A te wszystkie diagramy, artykuły Udi Dachan'a (z których z resztą sam się później wycofał) to ...
No nie wiem, ale mi się wydaje że ktoś z towarzystwa oszalał; mam nadzieję, że to nie ja.
Adrian C.

Adrian C.
projektant/programis
ta

Temat: CQRS czyli co....

Jakub Wojt:
CQRS to tak na prawdę bardzo prosty design pattern polegający na rozdzieleniu interfejsu serwisu na dwa w którym:
- pierwszy zawiera metody do realizacji przypadków użycia (metody które zmieniają stan systemu) - drugi zawiera metody do pobierania danych

Czy wyświetlenie listy produktów dostępnych w sklepie użytkownikowi nie jest prostym, lub kawałkiem UC? Wzorzec ten raczej polega na zbudowaniu dwóch stosów:
1) Rozkazy do aplikacji
2) Pytania do aplikacji
Przypadki użycia przeplatane są pomiędzy tymi dwoma stosami.
Jakub Wojt:
- wymusza na programiście / projektancie umieszczanie w serwisie logiki związanej z widokiem.

Co to jest serwis?
Jakub Wojt:
- nie ma żadnych konkretnych zalet poza potencjalnym poprawieniem wydajności (umieszczanie serwisów na odrębnych maszynach).

To bardzo duża zaleta nawet bez wdrażania tego na odrębne maszyny, poza tym nie mieszasz pytań z rozkazami, moim zdaniem dobry pomysł.
Uważam, że CQRS jest próbą ominięcia brzydkiej architektury (bałagan po stronie View spowodowany 'niekompatybilnością' DataModel Serwisu i View) poprzez przenoszenie i formalizowanie (nadanie nazwy, napisanie książki) bałaganu do serwisu (QueryModel / CommandModel).

Wzorzec ten to dwa stosy, więc nie ma tu bałaganu nie przenosi niczego do serwisu(czymkolwiek jest) stos odpowiedzialny za pytania w ogóle nie musi znać dziedziny, może to być nawet oddzielna aplikacja.
Wojciech Soczyński

Wojciech Soczyński Programista
eksplorator -
blog.wsoczynski.pl

Temat: CQRS czyli co....

Moim zdaniem sama idea CQRS jest dobra, ponieważ dzieli system wg jego naturalnego flow.
Query, odczyt danych do wyświetlenia ma zupełnie inną charakterystykę niż Command - wykonanie jakiejś operacji biznesowej.

W większości przypadków będziemy mieli więcej odczytów (Query) niż zapisów (Command) co daje pole do optymalizacji części systemów odpowiedzialnych za odczyt i zapis wg ich potrzeb.

Co do szczegółów tej architektury (wspomniane QueryModel czy CommandModel) nie zamierzam się wypowiadać, bo nie doszedłem tak głęboko ;P

konto usunięte

Temat: CQRS czyli co....

Czy wyświetlenie listy produktów dostępnych w sklepie użytkownikowi nie jest prostym, lub kawałkiem UC? Wzorzec ten
raczej polega na zbudowaniu dwóch stosów:
1) Rozkazy do aplikacji
2) Pytania do aplikacji
Przypadki użycia przeplatane są pomiędzy tymi dwoma stosami.

Tylko te modyfikujące dane. W serwisie nie ma metod typu "wyświetl .."
- wymusza na programiście / projektancie umieszczanie w serwisie logiki związanej z widokiem.

Co to jest serwis?

To jest to, co udostępnia aplikacji klienckiej funkcjonalność systemu.
- nie ma żadnych konkretnych zalet poza potencjalnym poprawieniem wydajności (umieszczanie serwisów na odrębnych maszynach).

To bardzo duża zaleta nawet bez wdrażania tego na odrębne maszyny,

Tylko że CQRS nie zostało stworzone po to, aby poprawiać wydajność. Jeśli miało by chodzić jedynie o to, to są na to dużo prostsze sposoby....
Mam prośbę - znajdź w poniższym artykule przyczynę / cel stworzenia CQRS. Wszystko się wtedy wyjaśni. :)
(http://codebetter.com/gregyoung/2010/02/16/cqrs-task-b...

PS: bez osobnych maszyn nie będzie poprawy wydajności.
Czyli taka architektura dedykowana dla sprzętu ;)
poza tym nie mieszasz pytań z rozkazami, moim zdaniem dobry pomysł.

Dlaczego mieszanie 'pytań' z 'rozkazami' na poziomie interfejsu jest złym pomysłem ?
Wzorzec ten to dwa stosy, więc nie ma tu bałaganu nie przenosi niczego do serwisu (czymkolwiek jest)

'query services update presentations from query model' (z diagramu).
Więc tak jakby mamy logikę (a przynajmniej fragment) View w dedykowanym serwisie.
stos odpowiedzialny za pytania w ogóle nie musi znać dziedziny, może to być nawet oddzielna aplikacja.

A po co tworzy się dziedzinę (model domeny) systemu ?

konto usunięte

Temat: CQRS czyli co....

Co do szczegółów tej architektury (wspomniane QueryModel czy CommandModel) nie zamierzam się wypowiadać, bo nie doszedłem tak głęboko ;P

A pisałeś, że używasz (bo preferujesz) :)
Wojciech Soczyński

Wojciech Soczyński Programista
eksplorator -
blog.wsoczynski.pl

Temat: CQRS czyli co....

Jakub Wojt:
Co do szczegółów tej architektury (wspomniane QueryModel czy CommandModel) nie zamierzam się wypowiadać, bo nie doszedłem tak głęboko ;P

A pisałeś, że używasz (bo preferujesz) :)
Napisałem: "Osobiście z powyższych powodów preferuje architektury w kierunku modelu publikuj-subskrybuj czy też CQRS."

Kluczowe jest słowo "w kierunku", które oznacza, że podoba mi się jakiś styl. Nigdzie nie jest napisane, że "osobiście używam CQRS bo uważam, że jest świetne".
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: CQRS czyli co....

z poziomu "laika" (nie programuję) wydaje mi się, że rozdzielenie specyfiki tworzenia obiektów na sztuki (bo tak biznesowo powstają) i zarządzania kolekcjami ma sens, czy przypadkiem operowanie zamiast kolekcją obiektów do dokonania np. złożonej statystyki lepiej jest w dziedzinie stworzyć odrębny obiekt, którego metody to złożone zapytania do tabli bazy?

załóżmy, że mamy serwis (usługę) obsługujący faktury, serwis ten operuje na pojedynczych fakturach (agregaty) ale gdy serwis ten "dostanie" zadanie wykonania złożonego raporty sprzedaży to skorzystał by nie z kolekcji faktur (setki lub tysiące agregatów) tylko z obiektu, którego metody operują na całej tablicy (tablicach) z fakturami.

wtedy model dziedziny ma:
- serwis obsługujący usługę zarządzania fakturami
- agregat opisujący fakturę
- dodatkowo klasę operującą na całej bazie faktur

odpowiedzialnością agregatu FaturaVAT jest operowanie pojedynczym dokumentem, odpowiedzialnością klasy KupaFaktur jest odpowiadanie na pytania dotyczące całego ich zbioru
???
Sebastian Kolski

Sebastian Kolski programista/DBA

Temat: CQRS czyli co....

Ja mam wrażenie, że opisywane są dwa systemy: OLTP i OLAP, operujące na tych samych danych. Ktoś postanowił, że będzie fajnie jak połączymy ich bazy danych i ich interfejsy.
Mnie osobiście takie rozwiązanie nie przekonuje.
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: CQRS czyli co....

Sebastian Kolski:
Ja mam wrażenie, że opisywane są dwa systemy: OLTP i OLAP, operujące na tych samych danych. Ktoś postanowił, że będzie fajnie jak połączymy ich bazy danych i ich interfejsy.
Mnie osobiście takie rozwiązanie nie przekonuje.

w pewnym sensie tak to wygląda: dwa modele dziedzinowe są "mapowane" na jeden model danych... tak to widzę, obowiązku nie ma ale nie raz może to pomóc...

konto usunięte

Temat: CQRS czyli co....

załóżmy, że mamy serwis (usługę) obsługujący faktury, serwis ten operuje na pojedynczych fakturach (agregaty) ale gdy serwis ten "dostanie" zadanie wykonania złożonego raporty sprzedaży to skorzystał by nie z kolekcji faktur (setki lub tysiące agregatów) tylko z obiektu, którego metody operują na całej tablicy (tablicach) z fakturami.

To oznacza bezpośrednie związanie logiki systemu (generowanie biznesowego raportu) z fizyczną realizacją warstwy persistence. Oczywiście takie powiązanie zawsze istnieje - klasy repozytoriów ale im takich powiązań mniej tym, według mnie, lepiej.
wtedy model dziedziny ma:
- serwis obsługujący usługę zarządzania fakturami
- agregat opisujący fakturę
- dodatkowo klasę operującą na całej bazie faktur

Tzn. można ostatecznie stworzyć oddzielne repozytoria tylko trzeba zadbać o to, żeby nie powielać kodu z repozytorium dla 'zwykłych faktur' (np. wspólna klasa bazowa).
Wtedy byłoby osobne repozytorium, osobny serwis, osobna klasa / agregat dla raportu.

... ale nie jestem pewien, czy dobrze zrozumiałem. :)
Tutaj chyba najlepiej by się rozmawiało w 'UML' ;)
odpowiedzialnością agregatu FaturaVAT jest operowanie pojedynczym dokumentem, odpowiedzialnością klasy KupaFaktur jest odpowiadanie na pytania dotyczące całego ich zbioru
???

można i takJakub Wojt edytował(a) ten post dnia 28.03.12 o godzinie 21:18

konto usunięte

Temat: CQRS czyli co....

Ja mam wrażenie, że opisywane są dwa systemy: OLTP i OLAP,

Ja myślę, że takie pytanie trzeba zadań autorowi koncepcji CQRS. Tzn. Jakiego typu dane ma zwracać Query Model i do jakich widoków... Bo oczywiście to też nie zostało wyjaśnione i każdy (krytyk / entuzjasta) to sobie (czy jest tego świadomy czy nie) dopowiada.

A może jest już za późno ma myślenie ... ;)
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: CQRS czyli co....

Posialiście u mnie "niepokój", wydawało mi się, że 'rozumiem" te ideę, ale chyba muszę trafić na problem i "odkryć" że to (taka architektura, wzorzec ) pomaga.... hm...

ale ogólnie wyobrażałem to sobie w ten sposób, że mając ów "agregat" i implementacje jego utrwalania, dodaję do tej pary dodatkowy model, który jest inną abstrakcją "tych samych danych"...Jarek Żeliński edytował(a) ten post dnia 28.03.12 o godzinie 22:58
Wojciech Soczyński

Wojciech Soczyński Programista
eksplorator -
blog.wsoczynski.pl

Temat: CQRS czyli co....

Ja uważam, że to działa tak: mamy jakiś model biznesowy dla niego mamy zdefiniowane operację (Commands), działają one na encjach w sensie DDD. Kiedy operacja biznesowa prowadzi do jakiejś zmiany w stanie encji, jest ona utrwalana na jakimś medium - w domyśle w bazie danych.

Mamy również zdefiniowane query, które mapują się do zestawu widoków - zagregowanych i pre generowanych danych powstałych na podstawie stanu encji, są one używane do wyświetlania.

Temat: CQRS czyli co....

Pierwszy raz zetknęłam się z omawianym tu wzorcem (czy raczej jego pierwowzorem) w kontekście programowanie obiektowego pod postacią zasady separacji poleceń i zapytań (Command-query separation principle). Z tego co wiem została ona zaproponowana w książce: Object-oriented Software Construction (Meyer, Bertrand, Prentice Hall, 1988). W tej pierwotnej prostej postaci chodziło jedynie o tworzenie osobnych metod zmieniających stan obiekt (poleceń) i sprawdzających stan obiektu (zapytań). Jest to prosta i pożyteczna zasada: jeśli obiekt ma publiczne atrybuty (proste lub wyliczane), to powinna być możliwość zbadania ich wartości bez zmiany stanu obiektu. W tej formie zasada ta nie jest sprzeczna z architekturą baz relacyjnych (wszak w SQL mamy osobną klauzulę - zapytanie: SELECT i 3 klauzule - polecenia: INSERT, UPDATE, DELETE). Nie wymaga także tworzenia osobnych modeli dla odczytu i zapisu (intuicja podpowiada mi, że nie byłoby to "ładne" w programowaniu obiektowym). Oczywiście, jak od każdej zasady, i od CQS są wyjątki.

CQRS w SQA idzie dalej: wprowadza segregacje odpowiedzialności - osobne interfejsy i osobne komponenty odpowiedzialne są za udostępnianie usług - poleceń i usług - zapytań. Idąc jeszcze dalej możemy wprowadzić osobne modele danych lub źródła danych. Jednak wydaje mi się, że trudno znaleść ogólny wzorzec, który powie czy segregować i jak głęboko dla więcej niż połowy przypadków. Jest po prostu zbyt wiele aspektów, które mają na to wpływ, np.: jaki zakres danych jest wymieniamy między dostawcą i odbiorcą usługi dla poszczególnych operacji, czy odczytujemy pojedynczą encję czy agregaty, czy odczyt ma zawsze zwrócić najświeższe dane, wymagania na niezawodność i dostępność poszczególnych operacji, częstotliwość wykonywania operacji.

Następna dyskusja:

z klas bo bazy czyli jaki w...




Wyślij zaproszenie do