Please enable JavaScript.
Coggle requires JavaScript to display documents.
CQRS - Coggle Diagram
CQRS
-
-
commands vs queries
commands
-
-
-
client does all the job of creating an object and doesn't expect anything to be returned, e.g. it generates id of the order and submits such command
imperative verb phrase instead of a noun , e.g. PlaceOrder instead of Order
message sent to a handler, something we want the handler to do
vs event
event is sent to many subscribers, and indicates sth that has happened, not the next step
-
-
Projektując model danych, zwykle wybieramy podejście Relacyjne i skupiamy się na wsparciu dla modelu domenowego - czyli dążymy do Trzeciej Postaci Normalnej. Postać ta, ze względu na brak redundancji, jest optymalna z punktu widzenia modyfikacji danych, zatem pożyteczna dla operacji typu Rozkaz. Natomiast postać ta w przypadku operacji typu Kwerenda skutkuje pojawianiem się iloczynów kartezjańskich (JOIN w SQL).
-
queries
-
odczyty stanu systemu – średnio w systemach biznesowych odczytów może być ok. 5 rzędów wielkości więcej niż zapisów
zawierają struktury nieodpowiednie do prezentacji – spadek wydajności spowodowany pobieraniem z bazy i przesyłaniem, nadmiarowych danych
agregowane w nich obiekty mogą zostać pobrane poprzez mechanizm Lazy Loading, który w przypadku danych przekrojowych powoduje pojawienie się zjawiska „n+1 Select Problem” – drastyczny problem z wydajnością, który jest w większości przypadków niedopuszczalny
-
posiadają metody biznesowe, które nie mają sensu w warstwie prezentacji
Serwisy Stosu Read, które nazywamy Finders, zwracają dane, których modele projektujemy na potrzeby konkretnych problemów (np. ekranów wyświetlających dane przekrojowe/raportowe). Są to zwykłe Data Transfer Objects (DTO), ponieważ Agregaty DDD nie nadają się do tego typu zadań z kilku powodów:
Statystycznie rzecz biorąc, ilość obsługiwanych rozkazów do ilości obsługiwanych kwerend (w jakimś interwale czasu) ma się jak 1 do kilkustet (tysięcy). Drugim aspektem – obok statystycznego - który różni oba typy operacji jest aspekt jakościowy modelu danych. Model danych potrzebny do wykonania operacji na modelu biznesowym oraz dane potrzebne do prezentacji wizualnej lub komunikacji z innymi modułami to zwykle inne struktury
-
-
-
why use it?
Gdy nie używamy
Mam możliwość korzystania z mechanizmu Lazy Loadingu,
który nie ma sensu dla operacji typu "pobierz dane do wyświetlenia" i prowadzi do dramatycznego problemu z wydajnością „N+1 Select Problem”,
W przypadku braku rozdzielenia silnik mapera wykonuje niepotrzebne operacje związane ze wsparciem dla Lazy Loading i Dirty Checking, które nie będą wykorzystywane
Pobieramy z ORM listę obiektów (zamapowanych na całe tabelki w bazie), gdy potrzebuję na ekranie jedynie kilku kolumn z każdej tabelki (dla bazy nie robi to różnicy, ale w
przypadku komunikacji sieciowej zaczniemy odczuwać skutki wydajnościowe tej decyzji)
Zdradzam model biznesowy warstwie prezentacji. Zdradzanie modelu domenowego wiąże się z drastycznym spadkiem bezpieczeństwa (wsteczna inżynieria) oraz z koniecznością koordynacji prac zespołów pracujących nad "klientem" i "serwerem", i zapewnianiem kompatybilności starszych wersji klientów
Pracujemy na puli połączeń zestawionej w trybie READ-WRITE, gdy wystarczający jest tryb READ – większość baz danych optymalizuje działanie w tym trybie.
-