Nie łapie sensu cqrs. Zwykle API ma osobne endpointy do czytania i pisania. Natomiast gdy są problemy z wydajnością to siła rzeczy trzyma się odpowiednik modelu do odczytu. Czy ktoś kto użył świadomie w projekcie cqrs może się podzielić przemyśleniami na ten temat?
0
0
W CQRS nie chodzi przecież o oddzielne endpointy tylko o oddzielne modele. A problemy z wydajnością różnie się rozwiązuje - a często to nawet wcale.
0
No o tym też słyszałem, ale nie wiem jak to wygląda w praktyce. Wtedy masz 2 tabele np. users? W jednej piszesz, a w drugiej czytasz? :D No chyba, że druga tabela to widok wtedy jeszcze jakoś zrozumiem, ale tak czy siak to nadal ten sam model, nie?
0
Tabele nie mają nic do tego, może ich w ogóle nie być. CQRS to wzorzec dla kodu aplikacji, a oddzielne modele to oddzielne klasy.
0
Skromny Karp napisał(a):
No o tym też słyszałem, ale nie wiem jak to wygląda w praktyce.
Różnie to wygląda w praktyce, bo jest to dość ogólny wzorzec, mówiący tylko o tym że mają być dwa modele, jeden do odczytu/query drugi do zapisu/command. Więc jest spore pole do popisu jak go zaimplementować, czy zastosujemy go jedynie na poziomie kodu, czy też na poziomie źródła danych, czy będzie synchroniczny czy asynchroniczny, w jaki sposób będziemy źródło danych do odczytu synchronizować, czy będziemy to robić synchronicznie, czy może asynchronicznie, czy będziemy denormalizować dane, a może naszym źródłem do odczytu będzie jakaś hurtowania danych, a może jeszcze do tego dodamy event sourcing :). Także jest naprawdę wiele możliwości.
Skromny Karp napisał(a):
Wtedy masz 2 tabele np. users? W jednej piszesz, a w drugiej czytasz? :D No chyba, że druga tabela to widok wtedy jeszcze jakoś zrozumiem, ale tak czy siak to nadal ten sam model, nie?
Istnieje scenariusz w którym możesz mieć dwie table users, ale one będą w dwóch oddzielnych bazach danych, jedna będzie służyła jako źródło danych dla modelu zapisu/command/transakcyjnego a druga będzie źródłem danych dla modelu odczytu/query/raportowania.
Ja jestem zwolennikiem w aplikacjach biznesowych robienia CQRS przynajmniej na poziomie kodu, ponieważ używanie ORM do robienia części query w ten sam sposób jak w części write z użyciem Query Objectów dla złożonych zapytań i zwracanie albo nadmiarowych danych lub niekompletnych encji, to jest zło. (no chyba że jest to CRUD, bez joinów i bez złożonych zapytań)
3
W zasadzie używałem CQRS, ze wzgledów wydajnościowych.
Duża ilość zapisów, zreplikowany system na zreplikowanej bazie danych (mulit master) itp.
Przeważnie na małym kawałku - kluczowe operacje.
I tyle.
Ja na to patrzę jak na potencjalnę możliwość skolejkowania zapisów, lub updatowania modeli. I jedyna rzecz, o której trzeba pamiętać to
aby podczas zapisu nie ulec pokusie skorzystania z read side (a zdarza sie).
Kiedyś mi wyszła wersja CQRS dla bardzo ubogich - baza SQL insert only. Po stronie zapisu robimy tylko INSERTy - update logiczny to nowy insert ze wskazaniem jaki rekord zastępujemy.
Odczyt to widoki (bo pozbieranie aktualnej wersji danych z takiej bazy jest srogie).
To było podyktowane życiem na bazie multi master i tym, że każdy UPDATE to było ryzyko (bo na innym nodzie ktoś mógł przypadkiem ten sam rekord updatować i sie robił konflikt wtedy).
Najczęścieś CQRS ma sens z kolejkami do przetwarzania zapisów i / lub updatu Read side. I jeszcze lepiej - z event sourcingiem.
Są frameworki, które w zasadzie wymuszają CQRS (np. akka-actors).
W kategorii porządkowania projektu niby CQRS pomaga się w części update skupić na tym, żeby po prostu wszystko sprawnie zapisać i nie przejmować się jak to bedzie czytane (może być koszmarnie trudne). Niby, bo o ilę rozumiem ten argument - to nigdy nie czułem, żeby się to podejście faktycznie w tym aspekcie przydało.
Wersja TLDR;
W zasadzie nie przejmował bym się CQRS. Sam Ci wyjdzie (i chyba tak to też widzisz) jak będziesz miał:
- nagłe, duże ilości zapisów, (i/lub)
- nagłe, duże ilości odczytów (raportów), (i/lub)
- system mocno rozproszony,
To pattern, który w trudnych sytuacjach pozwala Ci kupować wydajność i availability - płacąc spójnością (consistency).