Tworzyć dodatkową warstwę "service" czy nie

Witam.

Zerknie ktoś na ten kontroler fachowym okiem i wypowie się czy trzeba dodatkową warstwę, czy nie.

https://github.com/JakubGornickii/cryptodroid/blob/change/src/main/java/jg/cryptodroid/controller/ExchangeController.java

Czytając kod jednego kontrolera ciężko stwierdzić czy potrzebujesz dodatkowej warstwy - nie dodaje się kodu "bo inni tak mają", tylko wtedy kiedy jest on potrzebny (ba, nawet to co jest potrzebne zmienia się z rozwojem aplikacji, stąd potrzeba refaktoringów). Jak to jest jedyny kontroler w aplikacji PoC to może nie warto.

Chociaż muszę przyznać, że domyślnie dodaję tę dodatkową warstwę serwisów uzasadniając to zasadą jednej odpowiedzialności, kontrolery u mnie są raczej głupie - mają za zadanie udostępnić właśnie rzeczy biznesowe przez web, więc mają mapowania do URLi, może pomniejsze walidacje i tłumaczenia z/na DTO. Wtedy interfejsy serwisów opisują co można zrobić w aplikacji, jak zrobić - to już szczegół implementacyjny. No i testy takiej warstwy serwisowej mają szanse być prostsze, bo mogą wystarczyć jednostkowe z mockami.

(U Ciebie np. kontroler musi wiedzieć, że dane do wyświetlenia są w jakiejś stałej czy czymś i decydując się na trzymanie ich w jakiejś bazie nagle musisz zmieniać kontroler. Widać też sporo duplikacji związanych ze znalezieniem właściwego wpisu i obsługą niespodziewanych sytuacji. Serwisy rzucały by jakieś biznesowe wyjątki, które web tłumaczyłby sobie w jakimś ogólnym ExceptionHandlerze na pasujące kody HTTP - przy większej ilości kontrolerów/serwisów unika się znowu niepotrzebnego powtarzania.)

BTW, jedna uwaga - jest lista resource'ów jest pusta to zwracanie 404 nie jest poprawne (bo lista istnieje, tylko jest pusta).

Trzeba wydzielić logikę do osobnej klasy. A poza tym widzę dużo WTFów, np.:
https://github.com/JakubGornickii/cryptodroid/blob/change/src/main/java/jg/cryptodroid/exchangebase/ExchangeBase.java
Co to ogólnie ma być?

Lista wszystkich obiektów ExchangePaser. Dodaje do niej w konstruktorze każdy tworzony obiekt. Każdy z obiektów pobiera cały czas dane z jednej giełdy. Nie ma potrzeby nigdzie ich zapisywać tylko jak najszybciej znaleźć parę gdzie kupić taniej i sprzedać drożej i wysłać na front. Dlatego nie ma żadnej bazy danych tylko lista statyczna.

Ha, ja spojrzałem tylko nad podlinkowaną klasę w pierwszym poście, myślałem, że ta stała EXCHANGES to faktycznie stała (jakaś kolekcja "unmodifiable").
W takim razie przed rozważaniami o wydzielaniu warstw, odpowiedzialnościach itd radziłbym najpierw poczytać o wielowątkowości.