CQRS to wzorzec projektowy, który od kilku lat zdobywa co raz większą popularność, a mimo wszystko wydaje się dość mało popularny w świecie PHP. Na przykładzie doświadczeń z projektów legacy oraz greenfield pokażę jakie problemy dzięki niemu rozwiązaliśmy oraz jakie pułapki czekały za rogiem. Postaram się również odpowiedzieć na nurtujące pytanie: Czy CQRS jest odpowiedni dla mojego projektu?
3. CQS
1. Oddzielne metody zapisu i odczytu
2. Metoda zapisująca dane (Command method) nie zwraca
odpowiedzi
3. Metoda odczytująca dane (Query method) nie mody
fi
kuje ich.
Kilkukrotne wywołanie metody odczytu zwróci zawsze ten sam
rezultat.
31. Command Bus vs Event Bus
CommandBus EventBus
Ilość handlerów 1 <0, n>
Może
zwracać wartość?
Nie Nie
Może być
asynchroniczny?
Może być Może być
32. Po co mi Rozkazy i Zdarzenia?
1. Bardziej czytelny system - akcja -> reakcja
2. Idziemy w kierunku języka wszechobecnego
3. SRP - Single Responsibility Principle
4. OCP - Open Close Principle
5. High Cohesion (GRASP)
33. Asynchroniczny Handler
1. Długie operacje nie blokują odpowiedzi dla użytkownika
2. Mogą wykonywać się
na innej maszynie
3. Możemy użyć innej aplikacji, na przykład napisanej w innym języku
4. Async to również dodatkowe problemy :)
38. Read Model - Query
1. Przydaje się
wiedza z budowania zapytań SQL
2. ORM nie zawsze jest dobrym wyjściem
3. Możemy wykorzystać widoki w SQL
"Select * From Tabela" jestem mistrzem SQL’a :)
41. Kiedy nie używać CQRS
1. Aplikacje typu CRUD
2. Prosta logika biznesowa
42. Kiedy używać CQRS
1. Skomplikowania logika biznesowa
2. Aplikacja sterowana zadaniami - task based UI
3. Potrzeba optymalizacji / skalowania strony zapisu lub odczytu
4. Równoległa praca w zespole - bardziej doświadczone osoby powinny
skupić
się
na stronie zapisu, a mniej doświadczone na stronie odczytu
43. Plusy
1. Czytelniejsza architektura aplikacji
2. Łatwiejsze wydzielenie części synchro do asynchronicznej
3. Łatwiejsze skalowanie aplikacji
4. Jeden kod niezależnie od interfejsu wejściowego (API/UI, CLI, consumer)
