CQRS - identyfikacja zasobów, UUID
2017-07-10

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.