refactor kompletnie zepsutej architektury, czy da się to trochę poprawić bez pisania od nowa

Odziedziczyłem taki oto system.

Jest sobie klasa bazowa dajmy na to A, jest ona dodatkowo encją bazodanową (@Entity), ma ona kilka tam pól odwzorowanych w bazie danych. Ponadto niestety jest tam kilka-kilkanaście metod odpowiedzialnych za pewne funkcjonalności.

Klasa ta ma kilka klas pochodnych, rozszerzających klase A, ktore praktycznie nie mają pól odwzorowanych w bazie danych, ale też są encjami (pewnie tylko dlatego by był łatwy dostep do bazy danych). Przesłaniają te klasy 4-5 metod odpowiedzialnych za funkcjonalność, z klasy A + mają kilka prywatnych. Te przeslaniane metody wolaja zewnetrzne serwisy.

Główna funkcjonalność aplikacji to serwis, który wywołuje w okreslonej kolejności kilka metod z klasy A (lub przez póżne wiązanie te same metody z tych klas pochodnych).

Powiedzmy, że ta klasa A ma własnie kilka klas pochodnych, lepszej i gorszej jakości.
Próba refactoru jednej z nich jest bardzo bolesna, bo nie wiele można tak naprawdę poprawić.

Macie pomysł jak zacząć to poprawiać (z głową), by możliwie trochę poprawić jakość nie pisząc wszystkiego od nowa :)

Bardzo dużo ogólników podałeś, ale często pracuje się z odziedziczonym kodem. Nie zawsze ten kod jest najlepszy. Jeżeli znalazłbym w projekcie "code smelle", jak te opisane przez Ciebie, to pewnie postąpiłbym w taki sposób:

1. Spisał sobie gdzieś na boku wszystkie miejsca z code smellami
2. Pogrupował je na te, które wykonują zadania z tej samej kategorii
3. Stworzył fasadę, która je przesłania i wystawia ładniejsze, bardziej czytelne API
4. Spróbował wpiąć tę fasadę do obecnie używanych miejsc w aplikacji
5. W nowym kodzie używał fasady

Jeżeli w kodzie jest jakiś słaby fragment, z którym nie wiadomo co zrobić, to ważne, żeby nie rozlał się na całą aplikację. Jeśli już masz jakiś code smell, to najlepiej, jakby był tylko w jednym miejscu.
Nie wiem, odpowiedziałem na Twoje pytanie, bo bez kodu mamy tutaj takie rozważania akademickie. :)

To pierwsze co przychodzi mi do głowy ;]

Sugeruje zacząć od tego żeby całą logikę (czyli np. tą komunikacje z zewnętrznymi serwisami i te wywołania w odpowiedniej kolejności / orkiestracje) wyciągnąć do osobnych klas. Póki co te klasy mogą być jakośtam wrzucane do klasy A przez parametry albo jakiś service locator albo cokolwiek. Ale istotne jest żeby to wyciągnąć. Potem zacząłbym myśleć jak podzielic A na anemiczne DTO do komunikacji z bazą danych o ORMem i na klasy domenowe.

A masz testy - tego serwisu? Nie masz? - to miej. Od tego zacznij. Mogą być bardzo niekompletne.

Zrobiłbym tak jak Jareczek podpowiada. Zrobił takie tdd pod refactoring.

Rly? Czy Twój pracodawca też tak to widzi?

Zamiast poprawiać system od święta do święta to lepiej robić to iteracyjnie np. w ramach implementacji zadania przy okazji coś poprawić, dopisać test, zautomatyzować coś itp

Dzięki temu unikasz:

1. poprawiania czegoś co jeszcze może poczekać
2. przestrzelenia estymacji (np. skąd możesz wiedzieć ile zajmie Ci poprawienie wszystkiego jeśli dopiero się wdrażasz w system)
3. arogancji / wymądrzania itp

A jeśli będziesz systematycznie poprawiał małe rzeczy to zobaczysz, że pozostałe osoby w ekipie też to docenią i również w ten proces się zaangażują.