My idea with this post was actually to look at ways in which we can improve our architecture to get beyond MVC. If you read the final paragraph of the “Fear and Doubt” section, I actually discuss some reasons to keep business logic out of the models.

To me, the distinction is that when programming, we clearly need a place to hold the data in memory so that we can work with it. We also need a place to put logic that operates on that data. Depending on what data the logic operates on (whether, for example, it operates on one model or multiple), and the complexity of the data and the logic, it is often better to separate the functionality that encapsulates the data from the functionality that operates on that data.

Those are my views, anyway. If you have further thoughts, I’d really appreciate you leaving them.

“Represents the data used by the application, tends to also hold some amount of business logic. Also facilitates persistence (often by using or encapsulating some kind of data abstraction layer).”

MVC models do not “tend to hold some amount of business logic”. They are the business logic. This is a mistake made by many people who learned about MVC from Rails. Because of this mistake, some people add a fourth component or extensions that do not go in line with MVC (or plain violate it), and other people cram their business logic into controllers. Both approaches are wrong and invalidate MVC.