[Nofenak]

Piszę sobie taki projekt do zarządzania kinem i zastanawiam się jak ugryźć rezerwacje miejsc jeśli chodzi o moduły. Wymyśliłem na razie coś takiego, że moduł do rezerwacji pyta moduł katalogu (filmy, seanse, miejsca) o szczegóły miejsca (w kontekście rezerwacji interesuje mnie tylko czy miejsce jest dostępne i czas do seansu), po udanej rezerwacji publikuje event, że miejsce zostało zarezerwowane i moduł katalogu musi obsłużyć ten event i zmienić status miejsca na zajęte. Tylko, że teraz pojawia się problem z eventual consistency i rozposzoną transakcją (czytałem, że to anty pattern). Czy takie podejście jest ok czy powinienem to jakoś inaczej podzielić?
#programowanie #naukaprogramowania #ddd #mikroserwisy

[PaaD]

@Nofenak: IMHO moduł katalogu nie w ogóle nie powinien "interesować się" szczegółami sprzedaży (jeśli rozumiemy go tak jak w handlu, to będzie on odpowiednikiem wydrukowanej książeczki, w której treści nic się nie zmienia co chwilę za każdym razem gdy ktoś kupi bilet na film).

[Nofenak]

@PaaD: Jak to? Przecież w momencie sprzedaży zmniejsza się ilość produktów i trzeba też zaktualizować jej ilość w katalogu

[Coreq]

@Nofenak Raczej powinno być to rozwiązane sagą, czyli właśnie transakcja w rozproszonym systemie. Wg mnie nie ma sensu się pytać czy dane miejsce jest wolne podczas tworzenia rezerwacji, system powinien spróbować zaalokować dane miejsce na dany czas. Jeżeli się nie powiedzie to powinien on o tym poinformować i podać przyczynę czemu się nie udało.

[Krolik]

@Nofenak: @Coreq: po co Wam system rozproszony do tego? Jedna baza danych, trzymasz status każdego miejsca - wolne, zarezerwowane, sprzedane i tyle

[Nofenak]

@Krolik: Robię tę apkę w ramach nauki

[Coreq]

@Krolik Mi po nic xD Ale nauka polega na rozpracowywaniu takich prostych przykładów. Jak op pyta o mikroserwisy, to po co odpowiadać mu żeby sobie zrobił monolit.

[PaaD]

@Nofenak: Zmniejsza się ilość produktów, ale nie opisy czy godziny emisji filmów :) Potraktuj te serwisy jako metafory działów w firmie, i wyobraź sobie, że ktoś z kasy dzwoni do kogoś od ulotek poinformować, że właśnie sprzedało się bilet na jakiś film - za każdym razem. To nie to miejsce :]

[E.....o]

@Nofenak: wywal z katalogu informacje czy miejsce jest zajęte, wtedy znika ci problem że dane są zreplikowane, nie musisz wysyłać eventu i nie masz rozproszonej transakcji. To czy miejsce jest zajęte ustalasz sobie sprawdzając czy istnieje dla niego rezerwacja. Przy robieniu rezerwacji, robisz transakcje z wysokim stopniem izolacji albo jakiegoś rodzaju locking na bazie tego serwisu i po problemie pora na csa

[Nofenak]

@ElTalento: Ale po rezerwacji nadal trzeba poinformować katalog, że to miejsce już jest niedostępne

[E.....o]

@Nofenak: no wiem, dlatego mowie zebys usunal to pole, bo ono jest tam niepotrzebne i tworzy wiele problemow, katalog to katalog, to czy miejsce x jest zajete to juz jest context serwisu od rezerwacji

[Nofenak]

@ElTalento: Tylko po co user ma w ogóle próbować rezerwować miejsce o niewiadomym statusie? Powinien raczej dostać listę dostępnych miejsc

[tylko_zerknalem]

@Nofenak Wygląda na to że model który aktualnie posiadasz jest nieoptymalny. Moduł od rezerwacji powinien być źródłem wiedzy na temat rezerwacji konkretnego miejsca na konkretne wydarzenie. Pobieranie informacji o wolnych miejscach oraz zmiana ich statusu powinny korzystać z tego modułu. Miejsce na sali jest wtedy agregatem, który należy do bounded contextu rezerwacji i który pilnuje spójności danych wokół konkretnej rezerwacji. Wtedy ten agregat posiada referencję do wydarzenia z modułu katalogu. Katalog może