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ć?
0
0
nie podoba mi się zlewanie/mixowanie znaczenia moduł i mikroserwis
Sądzę, że i ciebie kopnie w ...
Również wydaje mi się, że ddd/ms dla jednego kina to overkill, i dlatego jest takie nienaturalne.
naturalnie by było sprzedawanie biletów do światowej sieci lotów pasażerskich (i eventual consistecy, z tego co słyszę, to tam słabo)
0
No tylko, że moduły to często takie mikroserwisy w monolicie tylko bez wydzielania do osobnej apki przez co znika dużo problemów infrastruktury.
0
A ja się zastanawiam dlaczego to moduł katalogu miałby być źródłem prawdy o rezerwacjach?
0
some_ONE napisał(a):
A ja się zastanawiam dlaczego to moduł katalogu miałby być źródłem prawdy o rezerwacjach?
Nie jest. On tylko udostępnia dane
0
To ok. W takim razie źle zrozumiałem opis, bo myślałem że moduł rezerwacji w momencie dokonywania rezerwacji pyta modułu katalogu czy dane miejsce jest wolne czy nie :D
0
Moduł katalogu udostępnia jedynie informacje czy miejsce jest wolne a potem już moduł rezerwacji decyduje co z tym faktem zrobić
0
oduł katalogu udostępnia jedynie informacje czy miejsce jest wolne a potem już moduł rezerwacji decyduje co z tym faktem zrobić — Nofenak dziś, 14:59
Jak z jutubowego wykładu "jak źle zaprojektować mikroserwisy".
a) Skrajnie niewydajne
b) proszenie się o hazardy
Nie jestem teoretykiem ani znawcą DDD itd i nie podam w pięknych poetyckich słowach, ale to c) ewidentnie te same dane i jest anty-rozwiazaniem robić 2 uS do jednych danych (jak powiedziałem, miksując słowa uS i moduł wcześniej czy pózniej wleziesz w krzaki / bagna)
Więc moduł w sensie architektonicznym (w obrębie tej samej całosci runtime) czy mikroserwis ? To zupełnie zmienia odpowiedź
Nie wiem jak tożsamościowo identyczne dane pobłogosławiłeś DDD, ale jak jest religia, to wszystko da się udowodnić
0
No tylko, że moduły to często takie mikroserwisy w monolicie tylko bez wydzielania do osobnej apki przez co znika dużo problemów infrastruktury. — ehhhhh dziś, 12:49
@ehhhhh: za dawno były książki, ale dla siebie odróżniam
a) sens architektoniczny "moduł = wydzielona jednostka projektowa / architektoniczna w obrębie tego samego runtime"
b) mikroserwis : wydzielona jednostka uruchomieniowa/ o niezależnym cyklu runtime / developmentu i innych. W praktyce jest jednym modułem (zdolnym do samodzielnego runtime), lub zestawem modułów w sensie a)
Pewnie wyjadacze znajdą w tym luki, ale tak na kolanie
0
Moduł rezerwacji nie pyta katalogu. Katalog to katalog, czyli baza z listą seansów do odczytu dla użytkownika. Jak w prawdziwym życiu zamawiasz z katalogu to też coś tam rezerwujesz?
Modelowanie mikroserwisów to trudna dziedzina. Spójrz jak to zostało rozwiązane tutaj:
Źródło: https://www.slideshare.net/sekarsadasivam/cinema-booking-system-movie-booking-system
2
Ostatnio w mojej bańce było to wałkowane wiele razy - modelowanie kontekstu dostępności. Przykład:
Generalnie, model powinien być tak podzielony, aby można było zachować spójność. W praktyce oznacza to, że w jednej transakcji musisz mieć dostęp do wszystkich danych niezbędnych do sprawdzenia warunków (tzw. niezmienników) i wykonania zapisu. Jeżeli zapis danych odbędzie się w innej transakcji, to oczywistym jest, że dojdzie do wyścigu i spójności nie będzie. Ergo, modeluj domenę w taki sposób, aby utrzymać spójność (na takim poziomie, na jakim potrzebujesz).
Do zaimplementowania rezerwacji na koniec dnia potrzebujesz atomowej operacji „compare-and-set”. Informacja o wolnych miejscach i możliwość ich zablokowania (albo informacja o blokadach) powinny być w jednym… agregacie z odpowiednio skonfigurowanymi poziomem izolacji transakcji.
0
Nofenak napisał(a):
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ć?
Nie wygląda jak zbyt dużo logiki - na prawdę musisz to rozdzielać?