Everything starts with a simple CRUD, you add the migration on the database, create the entity, insert a controller, a couple of views and everything seems fine. Then one feature after another the controller begins to grow, and begin to be more and more complicated and difficult to understand.

Rarely the software you are developing is just a CRUD, even if initially seems like this, every business domain has its own set of rules more or less complicated.

Then you realize that the framework architecture is not really perfect for your software, and you are right, because your architecture and your framework architecture are not the same thing, design your software is much more than deciding if some lines of code should be in a model or in a controller. You probably need classes to represent the concepts of your software domain, that are not pages, database tables and routes (that are the domain of your MVC framework), but maybe invoices, taxes, cost calculations or whatever your domain is about.

There are a few presentations that helped me to understand better how to put in practice these ideas:

• Unbreakable Domain Models
  your entity should map your domain, not just your database table

• Fat models must die
  some suggestions to take off behavior from your models with some good OOP

• Divide and Conquer
  how to extract your domain from the framework, and make it independent