Kiedy stosować wzorzec projektowy CQRS?

Cóż krytycy CQRL mogą powiedzieć, że CQRS jest skomplikowany i to może być prawda.

Oczywiście jest to dodawanie narzutu na rozwój prostej aplikacji CRUD w stylu CQRS, więc rozważyłbym użycie CQRS tylko w następujących przypadkach:

1. duży zespół - możesz łatwo podzielić zadania programistyczne między ludzi, jeśli wybrałeś architekturę CQRS. Twoi najlepsi ludzie mogą pracować nad logiką domeny, pozostawiając zwykłe rzeczy mniej wykwalifikowanym programistom.
2. trudny biznes logika - CQRS zmusza do unikania mieszania logiki domeny i operacji infrastrukturalnych.
3. skalowalność ma znaczenie - dzięki CQRS możesz osiągnąć doskonałą wydajność odczytu i zapisu, obsługę poleceń można skalować na wielu węzłach, a ponieważ zapytania są operacjami tylko do odczytu, można je zoptymalizować pod kątem szybkich operacji odczytu.

Gdy masz złożoną lub twardą domenę biznesową i:

• z event sourcing; chcesz fajny sposób testowania logiki
• z event sourcing; chcesz udowodnić swoje zachowania poprzez testowanie i rozumowanie
• masz wielu klientów lub konsumentów swojej usługi domenowej (nie tylko jednego serwera www)

Lub masz użytkowników, którzy muszą działać na wspólnych danych:

• i chcesz sformalizować koncepcje scalania danych twojej domeny
• lub ty chcesz zastosować logikę do scalania zdarzeń

Lub masz wymagania dotyczące skalowalności:

• stosujesz wzorzec jako wzorzec denormalizacji, który usuwa wąskie gardła
Chcesz skalować poziomo, a nie pionowo]}

Lub masz problemy z wydajnością (inna strona skalowalności):

• np. musisz przenieść swoją architekturę do architektury opartej na zdarzeniach - CQRS jako wzorzec jest dobrym krokiem.

Albo masz zespół, który jest fizycznie disjunct:

• np. część zespołu jest w innym kraju
Jeśli chcesz oddzielić modele odczytu od strony zapisu rzeczy (sagas, domain, CRUD), to trudno jest uzyskać komunikację twarzą w twarz, więc chcesz oddzielić modele odczytu od strony zapisu (sagas, domain, CRUD).]}

To nie CQRS jest zbyt skomplikowane, to komputery, które są.

Kiedy używać wzorca projektowego CQRS?

Wzorzec architektury CQRS może być używany, gdy trudno jest uzyskać z repozytoriów Zapytanie o wszystkie dane, które użytkownicy muszą wyświetlić. Jest to szczególnie ważne, gdy UX design tworzy widoki danych, które przecinają kilka typów agregatów i wystąpień. Im bardziej wyrafinowana jest Twoja domena, tym bardziej wydaje się to prawdą.

Gdy nie nadaje się do kompromisu w projektowaniu UX, użycie CQRS próbuje złagodzić problemy związane z innymi rozwiązaniami, np.:

• wymaganie, aby klienci korzystali z wielu repozytoriów do pobierania wszystkich zagregowanych instancji; lub
• projektowanie wyspecjalizowanych finderów na różnych repozytoriach w celu zebrania niepołączonych danych za pomocą jednego zapytania.

Podsumowując: używaj CQRS, gdy trudne do wyszukania dane z repozytoriów muszą być wyświetlane przez użytkowników, co zdarza się im bardziej wyrafinowana jest Twoja domena.

Z mojego punktu widzenia dodaje dwie główne korzyści.(Wśród wielu innych)

1. Ekstremalna zdolność skalowania
2. bardzo przydatne, gdy chodzi o distibuted zespołów.

W realnym świecie scenario CQRS może być przydatny, gdy masz klienta front end / web service, który potrzebuje dużo danych z wielu domen i pobieranie tych danych z bazy danych zajmuje dużo czasu.

W takim przypadku można rozważyć utworzenie oddzielnego modelu odczytu, który będzie szybciej rozwijany i może mieć szybszy czas wykonania.

Oto powody, dla których należy stosować CQR:

1. skalowalność (odczyt przekracza zapis, więc wymagania skalowania dla każdego różnią się i można je lepiej zaadresować)
2. elastyczność (oddzielne modele odczytu / zapisu)
3. zmniejszona złożoność (przeniesienie złożoności do oddzielnych problemów)
4. skoncentruj się na domenie / biznesie
5. ułatwia projektowanie intuicyjnych interfejsów użytkownika opartych na zadaniach