Hexagonal Architecture.
В MVC (по крайней мере в наиболее распространенной интерпретации в web'е) самое неприятное — контроллеры. В наивных примерах там содержится логика приложения (aka «толстые контроллеры»). Потом с ростом приложения возникают проблемы реиспользования кусков приложения и люди приходят к пониманию того, что нужны так называемые «тонкие контроллеры», а вся логика должна быть в
service layer, чтобы можно было использовать один и тот же кусок как с web, так и с CLI, так и с новой точки web (API или админка) и т.д. Далее люди приходят к пониманию того, что по сути тогда контроллер представляет из себя часть
presentation layer (aka view layer), потому что там нет логики, это просто тонкий слой между браузером и service layer:
PHP:
class ApiController extends Controller
{
/**
* @return array
*
* @Route("/", name="create_trip")
* @Template
*/
public function createTripAction(Request $request)
{
$form = $this->createForm(new CreateTripType());
$form->handleRequest($request);
if ($form->isValid()) {
$trip = $this->get('command_handler')->execute($form->getData());
return new Response('ok');
}
return array(
'form' => $form->createView(),
);
}
}
— форма, HTTP-request, etc. Это чисто presentation layer, а эту логику с валидацией можно безболезненно перенести на JavaScript. Ничего не изменится: просто в случае если пользователь отключит JS, то из-за exception'а из domain layer приложение будет падать с ошибкой.
Ещё раз: получается, что controller из MVC — это часть presentation layer, view. Контроллер — часть view? И тут появляется понимание того, что с MVC что-то не так: либо это неверная концепция, либо она настолько всеми не понята, то увы, теперь эту аббревиатуру в разговоре употреблять неудобно: появляется риск, что собеседник понимает под MVC что-то своё.