[Nofenak]

W jaki sposób rozbić monolit na moduły, które potem ewentualnie mogłyby stać się mikroserwisami? Słyszałem o różnych technikach typu bounded context, event storming itd, ale w takim monolicie wszystko wydaje się być ze sobą ściśle połączone i nie bardzo wiem, jak się do tego zabrać, np. co zrobić z joinami na kilka tabel? Czy transakcje rozproszone są ok czy unikać ich jak tylko się da? Itd. Pytam ogólnie, ale też w kontekście mojej apki do zarządania kinem, którą chciałbym właśnie zmodularyzować a potem przepisać na mikroserwisy: https://github.com/Sampeteq/cinema-app. Polecacie jakieś tutoriale, szkolenia, książki?
#naukaprogramowania #programowanie #programista15k #java

[quwer]

Leci 404 w repo

[LeopoldStuff]

@Nofenak: pierwsza sprawa to oddzielnie odczytów od zapisów/edycji może pomóc, czyli CQRS. Jak masz jakieś odczyty łączące różne dane z różnych obszarów to taki moduł może sobie być oddzielnym bytem który będzie tylko służył do odczytu danych.
Następnie pozostaje kwestia skupienia się na operacjach mutujących i próby rozbicia tego na moduły oddzielne. Zacząłbym od analizy i rozpiski operacji jakie wykonuje aplikacja, na podstawie tego określiłbym jakie dane/tabele są dotykane/potrzebne do danej

[JanPawelDrugiLechWalesaPierwszy]

@Nofenak: W wiem że się uczysz i nie chce się bardzo #!$%@?ć ale to co chcesz zrobić jest trochę bez sensu. Mikroserwisy mają sens w bardzo dużych projektach i jak je dzielić oraz w jaki sposób implementować zależy od bardzo wielu czynników których nie ma w małym przykładowym projekcie.

To trochę jakbyś przeczytał o dywersyfikacji inwestycji i zapytałbyś się w jakie różne instrumenty zainwestować 1 zł

Czy transakcje rozproszone są ok

[DonDikej]

@Nofenak tutaj jedno ze szkoleń o modularnym monolicie od devmentors
https://devmentors.io/szkolenia/modularny-monolit/

[nad__czlowiek]

W jaki sposób rozbić monolit na moduły

@Nofenak: prosta zasada, gówna nie ruszać póki działa xD
W międzyczasie przepisywać od nowa xD Najgorsze co można zrobić to rozbić monolit na rozproszone MAKROserwisy bo zazwyczaj tak się kończy rozbijanie monolitów, cięzko to robić na MIKROserwisy bo zazwyczaj jest tight-coupling. Jeśli ten monolit nie masz dobrze podzielony modułowo w sensie struktura projektu w kodzie (loose coupling) to będzie dosłownie grzebanie w gównie.

[afuera]

@Nofenak: każda tabelka = oddzielny serwis. Tych wyżej to nie słuchaj bo #!$%@? tam maja pojęcie o robocie

[pastarri]

@Nofenak: jest taka strategia rozbijania istniejącego już monolitu na mniejsze mikro serwisy, nazywa się Strangler-Fig Pattern.

Tu można poczytać: https://medium.com/@stephen.biston/practical-monolith-decomposition-the-strangler-fig-pattern-1aa49988072f

[mrpawel]

@Nofenak: Dlaczego potrzebujesz rozbijać monolit na mikro serwisy? Jeśli musisz, to pomyśl o tym jakie operacje muszą być natychmiast spójne (lokalne transakcje) a które mogą być eventual consistency (asynchroniczna komunikacja między mikro serwisami). Przejście w stronę modularnego monolitu może pomóc takie obszary w kodzie odnaleźć.