Definicja
CQRS (Command Query Responsibility Segregation) to wzorzec architektoniczny, w którym model zapisu (Commands) jest oddzielony od modelu odczytu (Queries). Każdy model może być niezależnie optymalizowany.
CQRS w praktyce
| Strona | Odpowiedzialność | Optymalizacja |
|---|---|---|
| Command (zapis) | Tworzenie, edycja, usuwanie | Walidacja, reguły biznesowe, transakcje |
| Query (odczyt) | Wyświetlanie, wyszukiwanie, raporty | Denormalizacja, cache, indeksy |
Kiedy stosować CQRS?
| Stosuj | Nie stosuj |
|---|---|
| Read/write ratio > 10:1 | Prosty CRUD |
| Złożone reguły biznesowe zapisu | Mała aplikacja |
| Potrzeba różnych widoków tych samych danych | Zespół < 3 osób |
| Wymaga event sourcing | Natychmiastowa spójność krytyczna |
CQRS + Event Sourcing
Często łączone:
- Command → walidacja → emit Event
- Event Store persystuje zdarzenie
- Projekcja przetwarza event → aktualizuje Read Model
- Query czyta z zoptymalizowanego Read Model
Dlaczego to ważne?
BA powinien rozumieć, że w systemie CQRS dane mogą nie być natychmiast spójne (eventual consistency). To wpływa na wymagania i oczekiwania użytkowników.
Co znaczy skrót CQRS
Skrót rozwija się jako Command Query Responsibility Segregation, czyli rozdzielenie odpowiedzialności za polecenia i zapytania. Przyjętego polskiego skrótu nie ma, więc w dokumencie zostaw wersję angielską i rozwiń ją w nawiasie przy pierwszym użyciu.
Dwa słowa z rozwinięcia są mylące dla analityka, bo w naszym języku znaczą co innego. Command to nie polecenie w sensie komendy w terminalu, tylko żądanie zmiany stanu: załóż wizytę, anuluj zamówienie, zmień adres. Query to nie zapytanie SQL, tylko żądanie odczytu: pokaż grafik, znajdź pacjenta, wygeneruj listę. Jeśli tłumaczysz to biznesowi, użyj pary „zmiana" i „podgląd" - trafia od razu.
Czy analityk musi to umieć? Odpowiedź z naszego job boardu
Zamiast zgadywać, policzyliśmy. Odczyt z tabeli ofert zasilającej Barometr rynku i moduł /praca, stan na 18 sierpnia 2026, 326 aktywnych ogłoszeń dla analityków (źródła: justjoin.it, rocketjobs.pl, NoFluffJobs, Adzuna):
| Termin w ogłoszeniu | Liczba ofert z 326 |
|---|---|
| API lub REST | 15 |
| Kafka albo RabbitMQ | 6 |
| mikroserwisy | 2 |
| event sourcing | 0 |
| CQRS | 0 |
Zastrzeżenie do liczb, żeby dało się je powtórzyć: wszystkie wiersze pochodzą z jednego zapytania, dopasowującego całe słowa w tytule oferty, w liście technologii i w zapowiedzi, a nie w pełnej treści ogłoszenia u wystawcy. To znaczy, że są dolną granicą. Dopasowanie po fragmencie zamiast po całym słowie podnosi pierwszy wiersz do 21, ale łapie przy okazji „kapitał" i „restaurację", więc go nie używamy.
Wniosek jest wygodny i niewygodny naraz. Wygodny: w żadnym z 326 ogłoszeń CQRS nie pada w tytule, w liście technologii ani w zapowiedzi, więc trudno to nazwać kompetencją rekrutacyjną dla analityka. Niewygodny: skrót i tak wpadnie ci do notatek, bo pada na spotkaniach architektonicznych, a wtedy trzeba wiedzieć, co z niego wynika dla twoich dokumentów. I to jest cała twoja robota w tym temacie: nie projektowanie wzorca, tylko wyciągnięcie konsekwencji.
Jedna konsekwencja, która realnie zmienia twoje dokumenty
Sekcja „Dlaczego to ważne?" wyżej mówi, że dane mogą nie być natychmiast spójne. Rozwińmy to, bo dopiero rozwinięcie jest użyteczne przy pisaniu - i zacznijmy od zastrzeżenia, które w większości tekstów o CQRS ginie.
Sam podział na model zapisu i model odczytu jeszcze nie oznacza opóźnienia. Jeśli rozdzielenie jest logiczne, w obrębie jednej bazy, i model odczytu aktualizuje się w tej samej transakcji co zapis, dane są spójne od razu. Opóźnienie pojawia się dopiero wtedy, gdy model odczytu jest aktualizowany asynchronicznie: osobnym procesem, przez kolejkę, przez projekcję ze zdarzeń. Ten wariant jest częsty i praktycznie pewny przy osobnej bazie odczytowej oraz przy połączeniu z event sourcingiem, ale nie jest definicją wzorca.
Dlatego pierwsze pytanie na spotkaniu nie brzmi „mamy CQRS?", tylko „czy model odczytu aktualizuje się synchronicznie, czy asynchronicznie?". Odpowiedź „synchronicznie" zdejmuje z ciebie cztery z sześciu punktów opisanych niżej. Odpowiedź „asynchronicznie" oznacza, że w systemie istnieje okno, w którym system mówi dwie różne rzeczy w zależności od tego, którą stroną go zapytasz - i to okno trzeba opisać. Zespół nazwie ten stan spójnością ostateczną (eventual consistency), tak jak sekcja „Dlaczego to ważne?" wyżej. To nazwa wariantu, nie przyznanie się do błędu, więc nie reaguj na nią jak na wadę do usunięcia.
Warto od razu zdjąć z drogi zastrzeżenie z tabeli „Kiedy stosować CQRS?" wyżej. Wiersz „natychmiastowa spójność krytyczna" dotyczy wariantu asynchronicznego. Przy aktualizacji w tej samej transakcji ten argument w ogóle nie występuje. A jeśli natychmiastowej aktualności wymaga kilka pojedynczych ekranów, a nie rdzeń systemu, to nie jest przypadek z tabeli: takie ekrany wskazuje się z imienia i zasila z modelu zapisu (punkt 4 niżej).
Przełóżmy to na przychodnię, na której uczymy w kursach. Rejestratorka MediFlow odwołuje wizytę pacjenta o 14:00. Polecenie idzie do modelu zapisu, wizyta jest odwołana. Rejestratorka odświeża grafik i widzi wizytę dalej na liście, bo grafik czyta z modelu odczytu, do którego zmiana jeszcze nie dotarła. Klika drugi raz. Dzwoni do IT. Zgłasza błąd.
Żaden błąd się nie wydarzył. Wydarzyło się to, co zaprojektowano. Brakuje wymagania, które to opisuje - i to jest brak po twojej stronie, nie po stronie zespołu.
Sześć rzeczy do dopisania w specyfikacji
Cała poniższa lista dotyczy wariantu z aktualizacją asynchroniczną. Przy synchronicznej odpadają punkty 1, 2, 4 i 5, bo nie ma okna, w którym dane się rozjeżdżają. Zostaje punkt 6, bo model odczytu ma inną strukturę i węższy zakres danych niezależnie od tego, kiedy się aktualizuje, oraz punkt 3, ale z zupełnie innego powodu, opisanego w samym punkcie.
To wszystko są pozycje, które ktoś musi rozstrzygnąć, a domyślnie nie rozstrzyga ich nikt.
- Dopuszczalne opóźnienie odczytu, per ekran. Nie „system ma być szybki", tylko liczba. Grafik rejestracji: do 2 sekund. Raport miesięczny dla zarządu: do 15 minut i to jest w porządku. To jest wymaganie niefunkcjonalne, a nie detal implementacyjny.
- Co widzi użytkownik w oknie opóźnienia. Trzy warianty do wyboru: ekran pokazuje stan sprzed zmiany bez żadnej informacji (najgorszy), pokazuje stan sprzed zmiany z adnotacją „dane sprzed chwili, odświeżanie", albo blokuje akcję do potwierdzenia. Wybór należy do biznesu, ale to ty musisz go z biznesu wyciągnąć, i to osobno dla każdego ekranu. W szerszym ujęciu, przy architekturze opartej na zdarzeniach, tę samą decyzję podejmuje się per zdarzenie; tutaj interesuje cię konkretny ekran i konkretny użytkownik.
- Zachowanie przy powtórzonym poleceniu. Ten punkt zostaje w mocy w każdym wariancie, bo powód jest prostszy niż architektura: zerwane połączenie, ponowione żądanie przeglądarki albo drugie kliknięcie niecierpliwego użytkownika. Przy asynchronicznym odczycie dochodzi jeszcze jeden powód, bo ekran nie potwierdza zmiany od razu. Zapisz wprost, że drugie identyczne polecenie nie tworzy drugiego skutku, i podaj okno, w którym ta ochrona obowiązuje. W języku zespołu to idempotencja, w twoim dokumencie to jedno zdanie w regule biznesowej.
- Który ekran musi być zawsze aktualny. Zwykle jest jeden lub dwa takie miejsca w całym systemie i zwykle wynikają z prawa albo pieniędzy: saldo przed przelewem, dostępność ostatniego miejsca, stan magazynu przy rezerwacji. Wskaż je z imienia, bo zespół zaprojektuje je inaczej niż resztę: zwykle zasila je wprost z modelu zapisu, kosztem wydajności.
- Co się dzieje, gdy przeniesienie do modelu odczytu padnie. Kto to zauważy, po jakim czasie, kto dostaje sygnał i co widzi użytkownik w międzyczasie. Bez tego awaria jest cicha, a cicha awaria danych jest najdroższym rodzajem awarii.
- Źródło prawdy dla raportów i reklamacji. Gdy klient dzwoni ze skargą, na podstawie którego modelu odpowiadacie. Odpowiedź „na podstawie modelu zapisu" brzmi oczywiście, dopóki nie okaże się, że dział obsługi ma dostęp wyłącznie do modelu odczytu.
Wszystkie sześć trafia do specyfikacji wymagań, ale do różnych jej części: punkty 1 i 5 do wymagań niefunkcjonalnych i uzgodnionego poziomu usługi, punkty 2 i 4 do opisu zachowania ekranów, punkty 3 i 6 do reguł biznesowych i polityk obsługi.
Kryterium akceptacji przy opóźnionym odczycie
Najczęstszy błąd w kryteriach to zdanie „po odwołaniu wizyty grafik nie pokazuje wizyty". Przy asynchronicznej aktualizacji modelu odczytu to kryterium jest nie do spełnienia w chwili zerowej i test je złapie jako błąd, choć błędu nie ma. Przy synchronicznej zdanie o grafiku jest w porządku i nic w nim nie zmieniaj, ale klauzulę o powtórzonym poleceniu zostaw. Jeśli wiesz już, że masz wariant asynchroniczny, popraw je tak, żeby zawierało czas:
Zakładając, że rejestratorka ma otwarty grafik na 20 sierpnia,
kiedy odwoła wizytę pacjenta z godziny 14:00,
wtedy w ciągu 1 sekundy widzi komunikat „Wizyta odwołana, grafik może przez chwilę
pokazywać stan sprzed zmiany",
oraz przy każdym odczycie grafika wykonanym później niż 2 sekundy po odwołaniu
grafik nie zawiera już tej wizyty,
oraz drugie identyczne polecenie odwołania tej wizyty, złożone w ciągu 30 sekund
od pierwszego, nie tworzy drugiego skutku.
Trzy liczby w tym kryterium mierzą trzy różne rzeczy i każdą ustala się osobno. Czas na informację zwrotną (1 sekunda) dotyczy potwierdzenia, że polecenie przyjęto; to potwierdzenie pochodzi z modelu zapisu, więc nie czeka na projekcję i może być najkrótsze. Okno opóźnienia odczytu (2 sekundy) wynika z architektury i mierzy, jak długo ekran może pokazywać stan sprzed zmiany. Okno ochrony przed powtórzonym poleceniem (30 sekund) wynika z czegoś zupełnie innego: z tego, jak długo użytkownik albo jego przeglądarka mogą ponowić żądanie po zerwanym połączeniu. Nie ma powodu ich zrównywać - zrównane w jednym zdaniu wyglądają na jedną decyzję, której potem nikt nie umie uzasadnić.
Zwróć uwagę też na to, od czego liczymy okno opóźnienia: od odwołania wizyty, a nie od kliknięcia „odśwież". Kryterium „2 sekundy od odświeżenia" spełni się też wtedy, gdy tester odświeży ekran po dziesięciu minutach, więc nie mierzy niczego. Ta wersja nie przesądza przy okazji, czy grafik odświeża się sam, czy ręcznie - to osobna decyzja, którą też trzeba zapisać, ale w wymaganiu o zachowaniu ekranu, nie tutaj.
Trzy rzeczy, które ta wersja załatwia: nazywa natychmiastową informację zwrotną, nazywa dopuszczalne okno i zamyka powtórzone polecenie. Reszta warsztatu pisania takich zdań jest w tekście jak pisać kryteria akceptacji; tutaj chodzi wyłącznie o poprawkę wymuszoną przez architekturę.
UAT: jak odróżnić błąd od projektu
W testach akceptacyjnych scenariusz „zapisz i sprawdź" jest odruchem. Przy asynchronicznym modelu odczytu ten odruch generuje zgłoszenia, które potem zamykacie statusem „działa zgodnie z projektem", i po trzecim takim zgłoszeniu biznes przestaje wierzyć testerom.
Trzy rzeczy przed startem UAT, jeśli model odczytu aktualizuje się asynchronicznie:
- Uprzedź testerów biznesowych na wejściu, że część ekranów odświeża się z opóźnieniem, i podaj im to okno w sekundach. Jedno zdanie w instrukcji do testów.
- Wpisz okno do scenariusza, nie do głowy testera. Krok „odśwież po upływie zadeklarowanego okna, dla grafika po 2 sekundach" jest tańszy niż wyjaśnianie tego pięć razy.
- Ustal z góry, jak klasyfikujecie zgłoszenie, gdy dane pojawiają się po przekroczeniu okna. To jest prawdziwy błąd i ma trafić na listę błędów, a nie do kosza razem z fałszywymi.
Szerzej o prowadzeniu tego etapu: UAT w praktyce i testowanie wymagań.
CQRS a pojęcia, z którymi bywa mylony
| Pojęcie | Czym się różni od CQRS |
|---|---|
| CQS | Starsza i węższa zasada z programowania obiektowego: pojedyncza metoda albo zmienia stan, albo zwraca dane, nigdy jedno i drugie. Dotyczy poziomu pojedynczej metody. CQRS przenosi ten pomysł z poziomu metody na poziom osobnych modeli danych i komponentów w obrębie jednego obszaru. |
| Event sourcing | Sposób przechowywania stanu jako ciągu zdarzeń. Bywa łączony z CQRS (patrz sekcja wyżej), ale CQRS działa też bez niego, a event sourcing bez CQRS. Pytaj o oba osobno. |
| Event-driven architecture | Szerszy styl komunikacji przez zdarzenia między komponentami. CQRS porządkuje jeden obszar od środka, EDA opisuje ruch między obszarami. |
| Mikroserwisy i DDD | Podział systemu na osobno wdrażane usługi i sposób wyznaczania jego granic. CQRS można zastosować wewnątrz jednego monolitu i nie mieć ani jednego mikroserwisu. |
| Replika odczytowa bazy | Chwyt czysto infrastrukturalny: ta sama struktura danych, kopiowana dla odciążenia. W CQRS model odczytu ma inną strukturę, dopasowaną do ekranu. Uwaga, żeby nie wyciągnąć z tego złego wniosku: replika ma własne opóźnienie, więc wszystkie sześć punktów z listy wyżej opisujesz tak samo. Odpada wyłącznie pytanie o strukturę modelu odczytu. |
| Hurtownia danych i ETL | Warstwa analityczna na kopii danych, zbudowana pod raportowanie i analizy historyczne, zwykle z osobnym cyklem zasilania i osobnym właścicielem. Model odczytu w CQRS zasila bieżące ekrany samej aplikacji, a dopuszczalne okno ustala się per ekran. |
Te pojęcia potrafią paść w jednym zdaniu na spotkaniu, więc rozgraniczenie przydaje się w praktyce, nie tylko w słowniku.
Cztery pytania do architekta
Krótka lista, którą możesz zadać, nie udając, że projektujesz system. Każde pytanie ma bezpośrednie przełożenie na dokument, który potem piszesz.
- Czy model odczytu aktualizuje się synchronicznie, czy asynchronicznie, a jeśli asynchronicznie, to jakie opóźnienie przyjmujemy za normalne i od jakiego mówimy o awarii? (wchodzi do wymagań niefunkcjonalnych)
- Które ekrany czytają z modelu zapisu, a które z modelu odczytu? (wchodzi do opisu przypadków użycia i na diagram sekwencji)
- Jeśli asynchronicznie: co się dzieje, gdy przeniesienie do modelu odczytu zawiedzie, i kto to zauważy? (wchodzi do scenariuszy alternatywnych i do monitoringu po stronie DevOps)
- Czy jest ekran, który musi być zawsze aktualny, i czy zespół o nim wie? (wchodzi do listy wyjątków i do wymagań, które zespół musi znać przed estymacją)
Cztery pytania, cztery akapity w dokumencie. Tyle wystarczy, żeby przestać być pasażerem na spotkaniu architektonicznym. Zostają jeszcze dwa punkty z listy sześciu, których na tej rozmowie nie zamkniesz: ochronę przed powtórzonym poleceniem (punkt 3) uzgadniasz z zespołem przy projektowaniu ekranu, a źródło prawdy dla reklamacji (punkt 6) z biznesem i obsługą klienta, bo to ich decyzja, nie architekta. Więcej o granicy między tą rozmową a robotą analityka systemowego: analityk systemowy a analityk biznesowy.
Częsty błąd: jeden model danych w dokumentacji
Analityk przynosi na przegląd jeden model pojęciowy i uznaje temat za zamknięty. W systemie z rozdzielonym odczytem to za mało, bo model odczytu bywa świadomie odklejony od modelu zapisu: ma dane zdenormalizowane, poskładane z kilku miejsc, przycięte do tego, co pokazuje ekran.
Rozwiązanie nie wymaga nowej techniki. Model pojęciowy zostaje jeden, wspólny słownik dziedziny się nie rozdwaja. Rozdwaja się warstwa niżej: diagram komponentów pokazuje osobno komponent obsługujący polecenia i osobno ten obsługujący odczyt, wraz z ich interfejsami.
Przy takim diagramie przydaje się zasada, którą w naszym kursie UML nazywamy regułą naczyń połączonych: każdy element modelu niższego poziomu ma mieć rodzica na poziomie wyższym, więc komponent istnieje dlatego, że realizuje jakiś przypadek użycia, a każdy przypadek użycia wynika z kroku procesu biznesowego. Komponent, dla którego nie umiesz wskazać rodzica, jest sierotą i kandydatem do wycięcia. Przy CQRS trzeba do tej reguły dopisać wyjątek i lepiej go znać, zanim ktoś wytknie ci go na przeglądzie: komponenty techniczne, czyli właśnie projekcja przenosząca dane do modelu odczytu, kolejka czy monitoring, nie realizują żadnego przypadku użycia. Ich rodzicem jest wymaganie niefunkcjonalne i tak je uzasadniasz - reguła nadal obowiązuje, tylko rodzic jest z innej półki.
Praktycznie: w specyfikacji trzymasz jeden słownik pojęć, a przy ekranach dopisujesz, z której strony systemu są zasilane. Rozwinięcie warsztatu diagramowego: diagramy UML w praktyce.
Krótkie odpowiedzi
Co CQRS zmienia w mojej pracy analityka? Dokładnie jedną rzecz, ale w wielu dokumentach: musisz opisać, czy i o ile ekran może pokazywać dane sprzed chwili, oraz co użytkownik wtedy widzi. Reszta wymagań zostaje bez zmian.
Czy CQRS zawsze oznacza opóźnione dane? Nie. Opóźnienie bierze się z asynchronicznej aktualizacji modelu odczytu, a nie z samego podziału na zapis i odczyt. Jeśli model odczytu aktualizuje się w tej samej transakcji co zapis, dane są spójne od razu. Zapytaj o to, zanim zaczniesz pisać wymagania o opóźnieniach.
Czy CQRS to to samo co event sourcing? Nie. To dwa niezależne wzorce, które często występują razem. Można mieć CQRS bez event sourcingu i odwrotnie. Na spotkaniu pytaj o oba osobno, bo odpowiedź „mamy CQRS" nie mówi, jak przechowywany jest stan.
Czy CQRS zawsze oznacza dwie bazy danych? Nie. Rozdzielenie może być logiczne, w obrębie jednej bazy: inne tabele, inne widoki, inne struktury. Dwie fizyczne bazy to jedna z możliwych realizacji, nie definicja wzorca.
Czy muszę znać CQRS na rozmowę o pracę na analityka? W 326 aktywnych ofertach z naszego job boardu skrót nie pada ani razu w tytule, w liście technologii ani w zapowiedzi (szczegóły i zastrzeżenie do liczb w sekcji o job boardzie wyżej). Znajomość konsekwencji dla wymagań jest natomiast dobrą odpowiedzią na pytanie „jak pracowałeś z zespołem przy trudnej architekturze".
Jak zapisać dopuszczalne opóźnienie, jeśli biznes nie umie podać liczby? Zapytaj odwrotnie: po ilu sekundach użytkownik uzna, że system nie działa, i zadzwoni. Ta liczba przychodzi natychmiast i jest lepsza niż wymyślona przez ciebie.
Kto decyduje o zastosowaniu CQRS? Architekt albo zespół deweloperski. Analityk nie decyduje, ale ma prawo poznać konsekwencje i obowiązek zapisać je w wymaganiach. Jeśli konsekwencje są nie do przyjęcia dla biznesu, twoim ruchem nie jest spór o wzorzec, tylko pokazanie konkretnego ekranu i konkretnego wymagania, którego w tym wariancie nie da się spełnić.
Gdzie iść dalej
- Definicja pojęcia, którym operuje ten tekst: kryteria akceptacji.
- Jak w ogóle rozmawiać z zespołem o integracjach: API dla analityka.
- Jak opisać dostępność i wydajność w specyfikacji: wymagania niefunkcjonalne w praktyce.
- Sprawdź się bez zakładania konta: test „Testowanie dla BA - UAT i kryteria akceptacji".
- Darmowe konto na platformie daje pierwszą lekcję każdego kursu i trzy podejścia do testów miesięcznie: rejestracja.
- Event-Driven Architecture
- Domain-Driven Design
- Mikroserwisy
- API