Refaktor serwisu, jak do tego najlepiej podejść?

Mam w projekcie serwis, który jest dość duży, ma ok. 1k lini kodu.
Serwis ten ma w sobie około 10~ metod, każda z nich pakuje odpowiednio event z odpowiednią logiką i wrzuca na topic kafkowy.
Każda z tych metod na początku wykonuje pewną common walidacje

Do głowy przychodzą mi dwa rozwiązania:

Klasa abstrakcyjna AbstractEventsProducer która miała by metode publiczną metodę processEvent() w której robiłaby tę common walidacje, do tego jakąś metode abstrakcyjną process() która by już była obsługiwana przez jej implementacje.
No i właśnie w tym wypadku miałbym 10 osobnych klas implementujących AbstractEventsProducer typu CustomerOrderChangeEventProducer itd.

Jakaś klasa np. EventsProducerGateway który przyjmował by w metodzie processEvent() enum jakiego dotyczy ten event, w środku common walidacja i jakiś switch, który przekierunkowywałby ruch dalej do processorów. Te processory to byłby klasy które mają zagregowane ze sobą metody dotykające podobnych domen.
Bo tak się składa żę mam np. 4 eventy w konteście Customera

Które z tych rozwiązań jest lepsze? Ewentualnie czy istnieje jeszcze jakaś lepsza alternatywa?

Te 10 operacji wydzieliłbym do 10 różnych strategii a same strategie dziedziczyły by po klasie bazowej z walidacją tak aby użyć wzorca: template method.

MrMadMatt napisał(a):

Te 10 operacji wydzieliłbym do 10 różnych strategii a same strategie dziedziczyły by po klasie bazowej z walidacją tak aby użyć wzorca: template method.

No ok, czyli coś ala moja wersja nr 1.

1. Napisz testy e2e serwisu.
2. Zrób refaktor.

Kod bez testów to zły kod. Nie ma znaczenia, jak dobrze jest napisany; nie ma znaczenia, jaki jest ładny, jak bardzo zorientowany obiektowo czy też jak mocno hermetyczny. Za pomocą testów możemy zmienić zachowanie naszego kodu szybko i w sposób weryfikowalny. Bez nich tak naprawdę nie wiemy, czy kod zmierza ku lepszemu, czy ku gorszemu.

"Praca z zastanym kodem. Najlepsze techniki" - Michael Feathers

Po pierwsze jaki jest problem z tym kodem? Z wątku wynika, że rozwiązanie jest brzydkie, bo nie mieści się na jednym ekranie? O to chodzi?

Podział jaki wprowadzisz nie jest za darmo, nowe bazowe klasy, które dodasz mają to do siebie, że narzucają interfejs. Jeśli pojawi się przypadek o którym nie pomyślałeś, i który coś złamie w interfejsie to taki nietrafiony podział jakiego teraz dokonasz więcej nasmrodzi niż pomoże.

Ze względu, że w pracy pracujesz nad konkretnym produktem, a nie tworzeniem frameworków :D to ja bym zostawił ten przypadek, aby tuczył się dalej. Jak rzecz zacznie sprawiać konkretne problemy to super, wtedy refaktor będzie prostszy bo będzie wiadomo co konkretnie boli.