Czy to już nadmierny formalizm?

Cześć, udało mi się w firmie przepchnąć refaktor 8 tysięcznikowych mikroserwisów. Chcemy je zrobić jako głębsze struktury i wydzielić kod do use casów.

Moje pytanie brzmi: jak bardzo jesteście za formalizmem w programowaniu?

No bo use case możemy zrobić po prostu jako klasę która nic nie implementuje i po prostu robi specyficzny przypadek, a możemy też dla każdego UseCase zdefiniować pewien kontrakt:

public interface UseCase<Q extends UseCase.Request, R extends UseCase.Response> {
    R execute(final Q request);
    interface Request { }
    interface Response { }
}

Dzięki drugiemu podejściu wiem, że jakiś np CreateOrderRequest jeśli implementuje UseCase.Request to jest wejściem do UseCase. Oczywiście Request i Response to zwyczajne znacznikowe interfejsy. Mogę też dzięki temu łatwiej potem dodać jakieś middle layery między use casami, a fasadami.

Podobne rozterki miałem w poprzedniej pracy - zaczynaliśmy podejście CQRSa i na początku sporo zagmatwania z definiowaniem abstrakcyjnych generycznych struktur, ale potem się to opłaciło, widzieliśmy zysk - łatwo było dodawać nowe rzeczy. Także ja jestem za formalizmem (na początku, jak się definiuje generyczne podstawy).

Nie wiem.
Rozumiem już, że daje Ci to jakieś tam znakowanie i porządkowanie (hmm czyli pakiety nie dają rady).
Czy zabezpiecza Cie to trochę przed jakimś typem błędu? Ułatwia szukanie problemu w razie błędu?

Lubię takie eksperymenty, ale płacę za nie chętnie tylko jeśli mi utrudniają popełnienie jakiegoś typowego błędu.
Jak się nie sprawdzi (albo znajdę coś ciekawszego) to porzucam.

Tu mała rada - jeśli, któregoś dnia odkryjesz, że ta konstrukcja jednak nic nie wnosi to po prostu ją zarzuć. Lepiej jest mieć niespójną architekturę, ale w 25% ładną niż spójną w 100% złą (wbrew obiegowym opiniom).