CQRS - Command Query Responsibility Segregation

Od ponad roku komercyjnie rozwijam system, w którym model domeny projektowany jest jedynie z uwzględnieniem zasad takich jak SOLID, CQS, Tell Don't Ask. Ani raz od samego początku nie musieliśmy iść na kompromisy z powodu wybranej technologii, wydajności czy ograniczeń wynikających z zewnętrznych narzędzi. Nie byłoby to możliwe gdyby nie CQRS, podział odpowiedzialności i bezwzględne przestrzeganie kilku prostych zasad. Mam nadzieję, że ten tekst będzie pierwszym z cyklu opisującego wykorzystanie CQRS w praktyce. Postaram się przedstawić kilka podstawowych pojęć tak aby kolejne, uzupełniające wpisy mogły posłużyć jako ich rozszerzenia. Mam nadzieję, że w ten sposób przedstawię temat lepiej niż w czasie 45 minutowego wystąpienia na żywo.

Zanim przystąpisz do czytania rzuć okiem na wprowadzenie do CQRS. W poprzednim wpisie wyjaśniłem po krótce czym jest CQRS oraz jakie jest jego zastosowanie. Tym razem skupie się jedynie na read modelu, czyli części Query.
Generowanie read modelu może okazać się bardzo skomplikowane, szczególnie kiedy model domeny nie do końca przekłada się na interfejs użytkownika. Chyba każdemu zdarzyło się dołożyć coś do encji tylko dlatego, że później w UI będzie to potrzebne, pomimo iż ta wartość nie ma żadnego znaczenia biznesowego. CQRS oraz rozdzielny read i write model świetnie rozwiązuje ten problem, pozwala dane mało istotne trzymać z daleka od tych krytycznych, ograniczając przez to ryzyko wprowadzenia systemu w nieoczekiwany lub niepoprawny stan. Dla mnie osobiście największą zaletą posiadania niezależnego read modelu, który może być przechowywany w zasadzie gdziekolwiek (nawet w pamięci) jest możliwość jego odtworzenia w dowolnym czasie, w dowolny sposób, nawet zmieniając zupełnie jego strukturę.

Każdy poprzedni wpis dotyczący CQRS'a mniej lub bardziej wspominał o systemie, czyli o takim bycie do którego trafiają wszystkie command oraz queries. Za pomocą komend, stan systemu może być zmieniony, query natomiast służy do jego odczytania. Przykładowo budując system do zarządzania pracownikami, komendą CreateUser() moglibyśmy dodać użytkownika do systemu a następnie korzystając z UserQuery::totalCount() : int moglibyśmy pobrać całkowitą liczbę użytkowników, którymi system zarządza. Czym jednak jest system?