Fat model / Fat controller: коли клас росте швидше за проєкт

Якщо у вас є модель на 1200+ рядків або контролер, який “трошки робить усе” — цей пост для вас 🙂

У Rails легко почати красиво. Але з часом у модель додається:• бізнес-логіка• інтеграції• callback-и• валідації• формування JSON• умовні переходи станівІ раптом один клас починає вирішувати пів проєкту. Ми всі через це проходили 🙂👉 У чому проблема🔹 Код важко читати🔹 Логіка розмазана🔹 Тести стають складними🔹 Будь-яка зміна ламає щось несподівано🔹 Новому розробнику потрібно пів дня, щоб зрозуміти “що тут відбувається”Модель перетворюється на “божественний об’єкт”.

👉 Чому це трапляється саме в Rails

Rails заохочує логіку в моделях. І на початку це правильно. Але:ActiveRecord ≠ місце для всієї бізнес-логіки. Модель відповідає за дані. А не за весь життєвий цикл домену. Як зрозуміти, що вже “fat”• файл важко прогорнути• методи не пов’язані між собою• з’явились 5+ callback-ів• модель знає про зовнішні API• ви боїтесь її чіпати👉 Що робити замість цього1️⃣ Service objectsВиносимо бізнес-логіку:ruby class CreateOrder def call(params) ... endend
2️⃣ Query objectsСкладні запити — не в модель.3️⃣ Form objectsОсобливо для складних форм і multi-step flows.4️⃣ PORO (Plain Old Ruby Object)Не все повинно бути ActiveRecord.

👉 Маленьке правило

Якщо метод не працює з полями моделі напряму — можливо, він не повинен бути в ній. Який найбільший файл моделі ви бачили? І скільки там було рядків?

😄

TikTok | Instagram | Telegram