CQRS - jak sprawdzana jest operacja przed zapisem?

CQRS za bardzo nie jest mi po drodze, ale mam pytanie na które nie wiem jaka jest poprawna odpowiedź.

Przykładowo mamy API wystawione do zapisu i API wystawione do odczytu. Front to jakoś sobie spina, OK.

Pytanie skąd API od zapisu wie:

• czy user jest zalogowany
• czy user ma uprawnienia związane z poszczególnym zasobem i operacją na nim?

W normalnym serwisie przed przyjęciem jakiejkolwiek mutacji byłoby sprawdzenie czy operacja jest dopuszczalna.

Stąd dochodzę do wniosku, że piszący musi ciągle znać bieżący stan.

Jak to robicie? Trzymacie cąłą bazę w RAM? W jakiej postaci, tworzycie sobie pod to kilka indeksów? Jak robicie na tym zapytania?

Czy może po prostu używacie np. postgresql jako master, a to API do odczytów obsługiwane jest ze slave'ów?

Poczytaj o JWT, oauth i openid. Sam token może posiadać informacje o tym co może. Natomiast w przypadku walidowani na podstawie danych z bazy/innych serwisów dobry cache rozwiązuje sprawę zbyt częstego odpytywania :)

Autoryzacja i uwierzytelnianie to tak zwane zwane "cross cutting concerns" i nie powinny one mieć nic wspólnego z architekturą aplikacji (to jest CQRS czy nie CQRS nie powinno mieć wpływu na kod związany z bezpieczeństwem).

Generalnie standardowe podejście to wyoutsource'owanie tego problemu do frameworku którego używasz, czy to Spring czy ASP.NET Core mają wbudowane mechanizmy związane z obsługą logowania itp.

Jeżeli potrzebujesz info o użytkowniku w bebechach aplikacji to zdefiniuj sobie interfejs UserProvider lub SecurityContext oraz value object User i niech ten interfejs będzie zaimplementowany w warstwie infastruktury z wykorzystaniem frameworku.

@pan_krewetek weź pod uwagę że w praktyce często masz coś w rodzaju "snapshot repository", więc co prawda zbierasz wszystkie eventy z commandami, ale jednocześnie masz (w pamięci albo chociażby i w SQLowej bazie!) "aktualny stan" na którym mozesz robić jakieś query i który modyfikujesz zgodnie z commandami. Niemniej do samego auth to raczej stosuje się takie rzeczy jak tokeny i session cookies.

Zacznijmy od tego że CQRS nie wymusza posiadania oddzielnych API (w sensie web API) od zapisów i odczytów. To tak dla wyjaśnienia.

Poza tym nie oznacza również że w obsłudze poleceń (command) nie możesz odczytywać danych z bazy czy jakiegokolwiek innego źródła. Przecież często- zależnie od wyboru technologii, frameworka itp.- trzeba np. wczytać encję aby ją zaktualizować i zapisać. A co w przypadku pełnoprawnej warstwy biznesowej gdzie strona poleceń musi dokonać walidacji zasad biznesowych przed wykonaniem polecenia? To oczywiste że wtedy trzeba sięgnąć po dane do bazy, czyli dokonać odczytu w ramach zapisu. W pewnym sensie CQRS wymusza odwrotność tego co Ty sugerujesz, czyli gwarancję że odczyty nie będą dokonywały zapisów. W drugą stronę to nie jest prawdą. Nie mówiąc już o tym że CQRS samo w sobie nie musi mieć nic wspólnego z bazami danych.

Poza tym Twój problem wydaje się nie mieć zbyt wiele wspólnego z CQRS, a z obsługą uwierzytelniania/autoryzacji ogólnie. Ale na to odpowiedzieli już koledzy wyżej.