CQRS to skrót od Command Query Responsibility Segregation. Jak sama nazwa wskazuje, podzieliliśmy aplikację na dwie części: po stronie poleceń i po stronie zapytania. Teraz ktoś zapyta, co oznaczają „polecenie” i „zapytanie”?

• Polecenia zmieniają stan obiektu lub encji, zwanych także modyfikatorami lub mutatorami.
• Zapytania zwracają stan jednostki i niczego nie zmieniają. Innym terminem na nie są „akcesory”.

W tradycyjnych systemach zarządzania danymi zarówno polecenia, jak i zapytania są wykonywane względem tego samego zestawu jednostek, które mają jedną reprezentację lub widok. Operacje CRUD są stosowane do pojedynczego magazynu danych i uzyskuje się dostęp do tej samej jednostki lub obiektu w celu obsługi operacji odczytu i zapisu.

Występują problemy z pojedynczym widokiem dla obu stron do odczytu i zapisu:

• Wprowadza ryzyko rywalizacji o dane.
• Zarządzanie uprawnieniami i zabezpieczeniami staje się skomplikowane, ponieważ te same obiekty są narażone na operacje odczytu i zapisu.

Wzorzec CQRS zakłada, że ​​metoda powinna albo zmienić stan jednostki, albo zwrócić wynik, ale nie oba. Oddzielenie modeli dla strony odczytu i zapisu zmniejsza złożoność związaną z posiadaniem jednego widoku dla obu stron.

Korzyści z CQRS

• Oddzielne modele poleceń i zapytań, co skutkuje uproszczeniem projektowania i implementacji systemu oraz ogólną redukcją złożoności.
• Można łatwo zoptymalizować stronę odczytu systemu niezależnie od strony zapisu, umożliwiając skalowanie każdej strony w inny sposób, zgodnie z obciążeniem po stronie. Na przykład magazyny danych do odczytu często napotykają większe obciążenie i dlatego można je skalować bez wpływu na magazyny danych do zapisu.
• W zależności od przypadków użycia możesz podać wiele widoków swoich danych do celów zapytań.

CQRS jest używany głównie w połączeniu z pozyskiwaniem zdarzeń. Model strony zapisu systemu opartego na CQRS obsługuje utrwalanie zdarzeń, działając jako źródło informacji dla strony odczytu. Odczytany model systemu zapewnia zmaterializowane widoki danych, zazwyczaj w postaci wysoce zdenormalizowanych widoków.

Poniższy diagram przedstawia szczegóły systemu opartego na CQRS:

Jak zaimplementować pozyskiwanie zdarzeń i CQRS

Jeśli korzystasz z architektury mikrousług do tworzenia aplikacji i chcesz wykorzystać zalety usługi Event Sourcing i CQRS, dostępne są różne struktury i platformy do tworzenia asynchronicznych mikrousług.

Eventuate jest jednym z takich przykładów. Jest to platforma aplikacji składająca się z dwóch produktów, z których jednym jest Eventuate ES , struktura mikrousług , która implementuje model programowania i trwałości oparty na źródle zdarzeń.

Lagom to platforma mikrousługowa typu open source zbudowana na bazie struktur Akka i Play. Lagom Persistence wykorzystuje Event Sourcing i CQRS, aby pomóc osiągnąć architekturę odsprzęgniętą.

Przykłady z życia wzięte, jak Lagom radzi sobie z pozyskiwaniem zdarzeń i CQRS, można znaleźć na następujących blogach:

• Trwałość danych w Lagom
• Trwałe czytanie strony w Lagom

Miłego blogowania!