По моему мнению, бизнес логика как раз и должна быть размещена в модели. Большая ошибка считать, что модель отвечает за работу с базой данных. Это же не коннектор базы данных.
Вся эта путаница возникает из-за того, что многие моменты предметной области пересекаются со структурой базы данных. Те же самые отношения между моделями конечно, позволяют удобно формировать сложные запросы, но в первую очередь хорошо отражают взаимосвязи внутри предметной области.
Кроме того, многие инструменты, которые дают фреймворки для работы внутри модели (события, доступ к старым данным, сеттеры/геттеры и др.) как минимум упрощают последующее понимание кода, резко ускоряют последующие дополнения и отладку.
Чтобы не запутаться в слишком толстой модели лучше всего каждый перед созданием нового метода задуматься: а нельзя ли его реализовать как квери билдер, геттер/сеттер или еще какой-то документированный метод фреймворка. Ну и конечно, никто не мешает из модели вынести какую-то объемную задачу в какой-нибудь выделенный сервис.
В итоге, из различных контроллеров можно просто запрашивать отдельные свойства модели, присваивать им значения. А вся сложная логика будет сконцентрирована в модели. И не нужно будет каждый раз переворачивать на изнанку весь код, если бизнес-логика немного меняется.