Rozbijanie crudowych serwsów na mniejsze klasy

Jest sens rozbijać crudowe serwisy np. TaskService na mniejsze klasy typu TaskChanger/ChangeTaskCommandHandler? Z pozoru brzmi sensownie, bo wtedy takie klasy mają jedną odpowiedzalność i łatwiej wydzielić interfejsy w razie potrzeby, ale z drugiej strony zazwyczaj jest jedna implementacja polegajaca na pobraniu encji z repo, wywołaniu jakieś metody na niej i ewentualnym mapowaniem na dto.

Warto, bo CRUDy istnieją tylko w projektach studenckich i jak się człowiek uczy programować. W praktyce zawsze prędzej czy później logika się rozbudowuje i TaskService będzie miał 5k linii kodu.

bo wtedy takie klasy mają jedną odpowiedzalność i łatwiej wydzielić interfejsy w razie potrzeby

Tak, bo mają jedną odpowiedzialność i są łatwiej utrzymywalne. Ale co do tego mają jakieś interfejsy? Co Ty chcesz wydzielać z tego?

Zdecydowanie, zwłaszcza w warstwie logiki aplikacji, gdzie przypadków użycia może być wiele. Widziałem już pojedyńcze handlery które robiły "za dużo". I teraz gdyby ta cała logika tych przerośniętych handlerów siedziała w jednej klasie obok innych mniej wysublimowanych handlerów to byłby dramat.

To że Twój use case w chwili obecnej polega na pobraniu obiektu z repozytorium, wykonaniu na nim jakiejś logiki, nie znaczy, że tak będzie zawsze. Jak @Grzyboo już napisał to w praktyce co iteracja dochodzą nowe wymagania co do logiki i siłą rzeczy sprawy się komplikują. Jeżeli rozwijasz projekt i myślisz przyszłościowo i nie chcesz za pół roku robić grubej refaktoryzacji to warto zacząć stosować podział klas na command/query handlery od samego początku. Narzut pracy nie duży zwłaszcza, gdy korzystasz z gotowych bibliotek, a zysk w perspektywie czasu ogromny.

W warstwie dziedzinowej serwisy są ok (Domain Services), bo zwykle mają ściśle określony cel i zakres odpowiedzialności.