Czy architektura typu klasa per akcja ma sens czy to overengineering? Np. CreateUserController -> CreateUserCommand -> CreateUserCommandHandler. Niby wprowadza to fajny podział i łatwo się to testuje, ale z drugiej strony wprowadza to spory narzut kodu i nie wiem czy to nie przesada.
0
1
Ma, jak najbardziej. Pomijajac czytelnosc kodu i inne praktyzne korzysci, wlasciwie uniemozliwia Ci naruszenie Single Responsibility Principle, chociaz wymaga spojnej struktury kodu i scislego trzymania sie wczesniej ustalonych regul.
1
Dążenie na siłę w SOLID to też antypattern. Wykorzystuj narzędzia tam, gdzie mają sens, a nie wszędzie gdzie tylko się da "Bo tak powiedział Wujek Bob".
To czy to przesada zależy od kontekstu aplikacji i biznesu.
Jeśli robisz szybkiego cruda i wystawiasz jakiś banalny interfejs i na tym kończy się apka to to jest overengeenering.
1
Jaki narzut kodu...? Nie wiem jaka technologia i ile boilerplate, ale masz wszystko czysciutko w każdym pliku. Ewentualnie, co ostatnio spotkałem to vertical slice, że masz sobie use case i w jednej klasie siedzi command, handler i definicja endpointu.
Z doświadczenia dużo bardziej wolę takie podejście niż wielkie serwisy 
2
Ale jaki język?
I co uważasz za akcję, jak chcesz ją implementować?
Zapewne (tak jak ja to rozumiem) potrzebujesz akcji, żeby zaprezentować pewien skutek uboczny, coś, co ma się zadziać w programie i chcesz to reprezentować w postaci obiektu.
Ale czy akcja ma sama być odpowiedzialna za uruchomienie się (jak w command pattern ) czy akcja może ma być tylko informacją, a same odpalenie skutku ubocznego (faktyczna obsługa akcji) będzie następowało gdzie indziej?
np.
CreateUserController -> CreateUserCommand -> CreateUserCommandHandler.
Te nazwy brzmią dość generycznie i bardziej jak budowanie infrastruktury apki. Nie brzmią domenowo, ale jak metaprogramowanie. Pytanie, czemu w ogóle tego potrzebujesz?