P-o-l-i-t-y-k-a, niezmienniki, auuuuu
Dobra, no to przeczytłem tego całego Brandoliniego i nic z tego nie rozumiem. O co chodzi z tą fioletową karteczką. Łatwiej było spisywać analizę w notatniku, na co komu te kartki.
Nic nie dygaj. Będzie dobrze. Przyklejasz fioletową kartkę zaraz po zdarzeniu. Natomiast po fioletowej kartce naklejasz niebieską i elo.
To żeś mi wyjaśnił. Nara.
Czekaj, świruję przecież. Fioletowa kartka obrazuje podjęcie decyzji procesowej na podstawie odebranego zdarzenia biznesowego. No w sensie, że wystąpilo jakieś zdarzenie i routujesz proces w odpowiednie miejsce. Być może musisz przypierdzielić tam jakiegoś ifa, który będzie decydował czy faktycznie reakcja powinna zajść.
Jakiego znowu ifa. Reguły przecież żółtą karteczką mieliśmy oznaczać.
Co racja to racja. No bo mamy tak naprawdę dwa rodzaje reguł (w zasadzie to więcej, ale uprośćmy trochę ten smutny świat). Reguły dotyczące procesu oraz reguły pilnujące spójności biznesu.
Uhuum.. mów dalej, ale już mi się to nie podoba.
Zacznijmy od fioletowej kartki. Rozgałęzia ona nam proces na różne, dozwolone i akceptowalne przez biznes, ściezki. Innymi słowy - w reakcji na jakieś zdarzenie reagujemy w konkretny sposób. Biznes mówi nam o regule pt.: słuchajcie, zawsze gdy potwierdzimy rezerwację to naliczamy punkty lojalnoścowe. Myslisz: aha... czyli mam zdarzenie "Potwierdzono rezerwację" i wówczas wchodzi do gry komenda pt.: "Nalicz punkty lojalnościowe". Prosty routing. Tak na marginesie: byłeś wcześniej programistą nie? No to zaimplementowałbyś taką fioletową kartkę jako event listener albo process manager, czy inny przerażający twór.
Okej... a ta źółta?
Na tych żółtych karteczkach umieszczasz reguły (niezmienniki), które muszą być spełnione, aby komenda się powiodła -> aby nie wprowadzić naszego systemu w niedozwolony stan. Spójności tej pilnuje tzw. agregat (DDD). To klasa, encja, która ma pewne zachowania (metody po prostu), a w tych metodach te super istotne ify pilnujące owej spójności
Daj no jakiś przykład lepiej jeszcze.
Skomplikujmy nieco kontekst. Powiedzmy, że składasz rezerwację i potwierdzenie takiej rezerwacji wiąże się z tym, że naliczane są punkty lojalnościowe. Ale, ale!! Ale tylko wówczas, gdy masz status 'KINOMAN' oraz gdy zamówienie zostało złożone kanałem MOBILE. Jak mógłbyś to zrobić.. Mógłbyś w module rezerwacji przechwycić zdarzenie o złożeniu rezerwacji, walnąć dwa ify: na statusie klienta oraz na polu channel. No i wysłać bądź nie wysłać żądanie naliczenia punktów lojalnościowych. Co o tym myślisz?
Trochę to śmierdzi miejscami.
Wiadomix, że śmierdzi. Bo dlaczego niby nasz wypieszczony mikroserwis rezerwacji miałby wiedzieć coś o KINOMANACH oraz o regułach rządzących przyznawaniem punktów. Biznes powiedział jasno - nie można naliczyć punktów lojalnościowych jeśli nie jesteś kinomanem. To jest super ważna reguła biznesowa (żółta karteczka), której nie możemy złamać. Ta reguła musi znajdować się w kontekście punktów a nie rezerwacji. Jeśli chodzi jednak o channel, to ma już to więcej sensu, aby umieścić ją w polityce. Jest to reguła, która mówi nam: Zawsze gdy potwierdzono rezerwację oraz rezerwacja została złożona kanałem MOBILE to nalicz punkty lojalnościowe.
Brzmi sensownie nawet.
Wiem, sam to w końcu wymyśliłem. No bo wyobraźmy sobie, że biznes podejmuje decyzje, że nie będzie to teraz status KINOMAN tylko ZWARIOWANY_KINOMANIAK - jeśli zostawilibyśmy tę regułę w kontekście rezerwacji, to musielibyśmy dodać zadanie do backlog'u w zespole rezerwacji, mimo że o zmianie zdecydował biznes zajmujący się punktami lojalnościowymi - dziwne kapkę... Inny przylad - reguła mówiąca o tym, że można zarezerwować miejsce w kinie o ile jest ono wolne.. To też super ważna reguła, której złamanie spowodowałoby smutek na twarzy klientów, a koniec końców naszych, bo musielibyśmy rozpatrywać reklamację, zwracać kasę, wizerunkowo też to słabo wygląda...
Dobrze, no już mówiłem, że brzmi sensownie. Idź już sobie.