CQRS nauka

0

Cześć,
Mam za zadanie napisać aplikacje webową w oparciu o wzorzec CQRS. Posługując się "teoretycznymi" przykładami na które natknąłem się na internecie ciężko przełożyć mi to na kod.
Znacie może jakieś wartościowe materiały które od A do Z tłumaczą ideę CQRS jako takiego z przykładami wykorzystania jako kod ? najlepiej w formie książki, wideo, ewentualnie treściwego artykułu.

0

Tu jest wszystko wytłumaczone: https://cqrs.files.wordpress.com/2010/11/cqrs_documents.pdf

W uporszczeniu chodzi o to, że do części 'command', która wykonuje akcje/komendy stosujesz dwie ścieżki kodu - pierwsza słuzy do pobierania danych (ale tylko potrzebnych do realizacji komend biznesowych) i zapisywania/usuwania/zmiany stanu i druga 'query', z którego wyciągasz tylko potrzebne dane. Przykład: rejestrujesz użytkownika - częśc biznesowa - komenda. Pobierasz dane o uzytkowniu i zapisujesz w częsci 'command'. Wyświetlasz listę użytkowników, szukasz postów po użytkownikach - część query. To wszystko nawet może hulać na jednej bazie danych pod spodem czy innym źródle danych, chodzi o to, że wszystkie biznesowe akcje maja być spójne i zawsze mieć najświeższe dane, natomiast częśc query może być 'ewentualnie spójna', ale za to ma się świetnie skalować lub umożliwiać skalowanie w przyszłości.

1

Tylko po co tu pchać od razu jakieś "repozytoria"? Można to wszystko przecież zaimplementować normalnie, bez nieudolnych implementacji wzorców z innej klasy abstrakcji.

0

A jakie to sa te złe implementacje repozytoriów? I co w zamian?

0

Złe to takie, w których byle DAO jest nazywane repozytorium. W zamian nazywanie rzeczy po imieniu.

0

A czym jest prawdziwe repozytorium?

6

Chodzi o to, że obecnie (niestety) zatarła się różnica między DAO a Repository (mam odczucie, że w Javie dzięki Spring Data JPA w szczególności mamy z tym do czynienia). Oba wzorce działają na innych poziomach abstrakcji.

  • Repository jest tworem na wyższym poziomie abstrakcji i bliżej mu do DDD. DAO to DAO, ot taki wzorzec, z DDD nie ma nic wspólnego.
  • Repository powinno być powiązane z jakimś typem kolekcji i zwracać tylko je. DAO służy ogólnie to wyciągania danych - różnych danych. Jeśli chcesz pobrać wiek 10 najstarszych użytkowników - DAO zwróci Ci po prostu kolekcję 10 intów, Repository powinno Ci zwrócić 10 całych użytkowników. Jeśli będziesz chciał wykonać zaawansowanego SQLa i zwrócić coś dziwnego to skorzystasz z DAO.
  • Repository jest IMO ściśle powiązane ze tzw. Specyfikacjami jeśli chcesz wykonywać bardziej zaawansowane operacje wyszukujące. DAO czegoś takiego nie ma bo jest bardzo blisko SQLa.

Mam nadzieje, że nie popłynąłem za bardzo. Trochę uczepiłem się tego SQLa, ale najczęściej korzystamy pod spodem właśnie z niego ;)

3

@miszasty93: dobre podsumowanie, chociaż Specyfikacje tak naprawdę nie są konieczne, równie dobrze repozytorium może wystawiać konkretne metody odpowiadające przypadkom biznesowym. I szczerze mówiąc ja preferuję takie podejście, bo specyfikacji to dla mnie taki trochę wyciek abstrakcji.
I masz rację, że najczęściej używamy SQL, ale nic nie stoi na przeszkodzie, żeby źródłem danych dla repozytorium był plik albo usługa sieciowa. Właśnie o to chodzi z repozytoriami, że stanowią abstrakcje i zwracają obiekty, nieważne skąd.

0

A jeśli potrzebujemy tylko jednego użytkownika to już nie możemy użyć Repository, bo on zwraca kolekcję? Chyba że pobrać kolekcję z jednym elementem? Tylko czy to nie bez sensu?
Czyli taki ogólny podział to DAO zwraca proste dane, a Repository obiekty?
Tylko że jak ktoś chce 10 najstarszych użytkowników to mało prawdopodobne, że same ID mu się przydadzą, więc tak naprawdę DAO jest mało użyteczne. Chyba że np Repository do wyszukania korzysta z DAO i zwraca obiekty?

0

Repozytorium nie ma zwracać dowolnych obiektów tylko Aggregate Rooty. Czyli, aby w ogóle rozmawiać o repozytorium trzeba mieć aplikację tworzoną zgodnie z DDD. W przeciwnym razie mamy jakieś DAO, nieważne czy zwraca inty czy obiekty.

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0