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ę.

Ten wpis jest jednym z kilku rozszerzeń jakie planuje napisać do CQRS w praktyce, wprowadzenie - PHP. Kilka osób zapytało w jaki sposób najlepiej radzić sobie z walidacją, skoro architektura poruszona w poprzednim tekście składał się z warstw to w której warstwie powinno się umieścić walidację? Pierwsze co nasuwa się na myśl to interfejs użytkownika, w końcu ta warstwa jest najbliżej użytkownika. Jednak ciągle wspominałem o tym jak to model domenowy powinien być kuloodporny, jak to obiekty powinny same dbać o poprawność swojego stanu. No więc może lepiej umieścić walidację w modelu domeny? Tak naprawdę obydwa te miejsca są odpowiednie, jednak walidacja w nich umieszczona ma zupełnie inne przeznaczenie.