Ostatnio zastanawiałem się nad dwoma podejściami tworzenia aplikacji. Jeden z nich to wiele modułów podzielonych tematycznie kompilowany do jednej aplikacji, a drugim podejściem że każdy z tych modułów tematycznych kompilowany jest do oddzielnej aplikacji komunikujących się ze sobą po rescie. Oczywiście mają jakiś wspólny że sobą common, ale są oddzielnymi bytami. Zastanawiam się nad zaletami i wadami podejść, jaki ma to wpływ na wydajność etc. Nie wątpliwie drugie podejście ma zaletę taka że takie moduły do oddzielnych aplikacji łatwiej wymieniać na nowe - tylko że podejrzewam że takich sytuacji jest promil. Jakie wy chętniej preferujecie podejście i czym się kierujecie w wyborze? Czas to kryterium drugorzędne, przede wszystkim chodzi o jakość tych rozwiązań.
No nie, to w ogóle jakby zapytać czy lepiej kupić większe koła do roweru czy kupić jeepa. Modularyzacja a rozproszenie to 2 różne tematy, to drugie jest bardzo drogie. Odsyłam do wujka Folwera: https://martinfowler.com/bliki/MonolithFirst.html i talka o modularyzacji
turo90 napisał(a):
Ostatnio zastanawiałem się nad dwoma podejściami tworzenia aplikacji. Jeden z nich to wiele modułów podzielonych tematycznie kompilowany do jednej aplikacji, a drugim podejściem że każdy z tych modułów tematycznych kompilowany jest do oddzielnej aplikacji komunikujących się ze sobą po rescie. Oczywiście mają jakiś wspólny że sobą common, ale są oddzielnymi bytami.
Niekoniecznie. Joe Armstrong podobno stwierdził:
The problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.
Takie coś jest możliwe w przypadku modularnego monolitu, ale w przypadku mikroserwisów już niespecjalnie. Jeśli przesyłasz banana RESTem to nie dokładasz do niego całej dżungli. Natomiast jeśli w OOPie przesyłasz obiekt Banana (z jednego miejsca monolitu do drugiego) to ten bez problemu może się w środku do całej dżungli odwoływać.