Fat model / Fat controller: коли клас росте швидше за проєктЯкщо у вас є модель на 1200+ рядків або контролер, який “трошки робить усе” — цей пост для вас 🙂У Rails легко почати красиво.Але з часом у модель додається:• бізнес-логіка• інтеграції• callback-и• валідації• формування JSON• умовні переходи станівІ раптом один клас починає вирішувати пів проєкту.Ми всі через це проходили 🙂👉 У чому проблема🔹 Код важко читати🔹 Логіка розмазана🔹 Тести стають складними🔹 Будь-яка зміна ламає щось несподівано🔹 Новому розробнику потрібно пів дня, щоб зрозуміти “що тут відбувається”Модель перетворюється на “божественний об’єкт”.👉 Чому це трапляється саме в RailsRails заохочує логіку в моделях.І на початку це правильно.Але: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