Dobra organizacja większych aplikacji springowych

0

Witajcie,
Ostatnio zauważyłem że architektura projektu napisanego w Springu, który hoduję od ok 6 miesięcy nie daje rady (moim zdaniem).
Problem polega głównie na złożoności logiki biznesowej jak i mnogości funkcji oferowanej przez produkt.
Dodatkowo klient ma dość chore wymagania, jak pokazywanie moim zdaniem zbyt dużej ilości informacji na 1 widoku (co wiąże się ze wrzucaniem ogromnej ilości propertiesów do modelu we wzorcu MVC), ale nie z tym do was przychodzę.
Związku z tak ogromną ilością funkcjonalności powstało dużo serwisów, a w nich ogrom zagmatwanych metod. Chciałbym zabrać się za refactoring tego kodu, lecz nie wiem od czego zacząć.
Czy architektura serwisowa znajduje w ogóle zastosowanie w większych projektach? Czy lepiej zrobić to inaczej? Jak inaczej to jak?
Jak pozbyć dużej ilości pól wstrzykiwanych do każdej z instancji serwisów?

Pozdrawiam i liczę na wasze wskazówki, jak utrzymać ten projekt, by jego rozwój był przyjemnością, a nie płaczem :)

0

Też chętnie się dowiem, co na ten temat myślą @Shalom @somekind @katelx @Lectre. Od siebie napiszę, że jak najbardziej, warstwowa architektura jest okej. Prawda, że przy złożonej logice, serwisy będą miało sporo wstrzykniętych innych serwisów. Kluczem tutaj będzie dobre projektowanie kolejnych metod pod względem poziomu abstrakcji - jeśli coś dotyczy w większości encji X, to piszę tą metodę w serwisie do X.

1

Niejako tutaj: http://4programmers.net/Forum/Inzynieria_oprogramowania/276798-wstrzykiwanie_zaleznosci_a_testy_jednostkowe_-_zloty_srodek?p=1288229 toczy sie dyskusja zbliżona ;)
Myślałeś może o podejściu Backend-as-a-service i mikroserwisach? Wyobraź sobie że zamiast w jednym biednym kontrolerze zbierać wszystkie możliwe informacje a potem upychać do modelu zeby wyrenderować widok mozesz to zrobić zupełnie inaczej:

  • Masz wiele małych, specjalizowanych kontrolerów @RestController które zwracają bardzo konkretne dane jako jsona
  • Po stronie frontendu masz ajaxowe wywołania javascriptu które pobierają z twoich kontrolerów dane i wyswietlają je.

To powinno pomóc w obu kwestiach. Logika biznesowa trochę się odseparuje, bo nie będziesz potrzebował już serwisów "zbierających" dane z wielu miejsc. Powinno to też ułatwić pracę z klientem, bo teraz dodanie nowych danych to jest dodanie nowego modułu z jego własnym kontrolerem, a nie dopisywanie i przerabianie istniejącego.
Jeśli chodzi o podejście serwisowe to się sprawdza, ale może warto pomyśleć o jakiejś hierarchii i poziomach abstrakcji?

0

@Shalom Hierarchii i poziomach abstrakcji? Co masz dokładniej na myśli?

2

Na myśli mam że zamiast wstrzykiwać 10 zależności do jednej klasy można je zwykle zgrupować i wstrzyknąć np. 3 serwisy grupujące (z których każdy ma 3-4 zależności). Czyli tworzysz kolejny poziom abstrakcji.

1

Pracuję teraz w projekcie na ~700k linii samej Javowej logiki, zastosowana jest architektura serwisowa, więc jak najbardziej znajduje zastosowanie w większych systemach. W dodatku czytelność i utrzymalność na relatywnie wysokim poziomie. Wszystko dzięki modularyzacji i mikroserwisom. W rzeczywistości każda funkcjonalność to osobny byt, który można osobno zbudować, osobno uruchomić i osobno przetestować. Niemniej wątpię by przepisywanie całej aplikacji na mikroserwisy było rozwiązaniem na twoje bolączki.

Jak sam mówisz, upychasz do modelu wszystko jak leci, a to źle. Stwórz, tak jak mówił Shalom osobne RESTowe endpointy wysyłające małe paczki danych. Dodatkowo część logiki możesz przerzucić na JS, nie mówię tu o zaprzęganiu Angulara, bo w tym przypadku byłoby to bez sensu, ale np. formatowanie danych możesz zrzucić na front-end, wtedy zamiast tworzyć 10 kontrolerów do jednego zasobu (albo jednego uber kontrolera z 10 parametrami) tworzysz bardziej generyczny kontroler. Oczywiście to raczej zasada kciuka i nie trzymaj się tego sztywno, żeby na przykład nie wysyłać wrażliwych danych tam gdzie nie są potrzebne. Anyway, you get the concept.

Ciekawy temat, czekam na pomysły innych :)

0

Dziel i rządź. Bez kodu trudno zasugerować coś więcej.

1 użytkowników online, w tym zalogowanych: 0, gości: 1