🏗 Fat controller, fat model, fat service — выбери, где тебе будет больно

Бизнес-логику нужно куда-то положить. Вечный спор не про «как правильно», а про то, какую боль ты выбираешь осознанно.

🔹 В контроллере.

Быстро на старте, через полгода контроллер на 400 строк, логику нельзя переиспользовать из консольной команды, тесты требуют поднимать HTTP-слой. Боль: дублирование и непереиспользуемость.

🔹 В модели (Active Record).

Логика рядом с данными, удобно. Но модель начинает знать про отправку писем, платёжные шлюзы и очереди. God-object, который тащит за собой полприложения в каждый тест. Боль: связность.

🔹 В сервисах / Action-классах.

Логика отделена от транспорта и от хранилища, тестируется на чистых данных. Цена — больше файлов и дисциплина, чтобы сервис не превратился в свалку из 30 методов. Боль: дисциплина.

Практичная середина, которая выживает дольше всего: тонкий контроллер (валидация + вызов), модель хранит данные и простые инварианты, Action/сервис держит сценарий. Один use-case — один класс с одним публичным методом. Растёт линейно, читается за минуту, тестируется без фреймворка.

💬 Какие проекты на каком варианте пишете?

Библиотека пхпшника