> As much business logic as possible should belong in the model. Services should almost all be specific more complex pieces of code that are triggered from the model.
In my experience with fat models is that it works for trivial cases. Once you get more complex business rules that span multiple models, the question becomes which model should it be implemented on. For example in a e-commerce app you might need to evaluate User, Product, DiscountCode and InventoryRow tables as part of a single logical business case to determine the final price. At that point it doesn’t make much sense to implement it on a model since it’s not inherent to any of them, but a PriceCalculator service makes sense.
We have one model file per db table (a "repository") in which we define all queries that "logically belong to that table" (sure they do joins and/or sub-queries that involve other tables, but they still "logically belong to a specific table").
Once we need logic that combines queries from several "repositories", we put that in a "service" file that's named after what it does (e.g. PriceCalculator).
Most of our business logic is in the models (repositories and services), other encapsulated in the SQL queries. Repositories never call services. Model code never calls controller code. Pretty happy with it.
We'd not call it a model, we have no notion of "a model", merely a package called "models" (in line with MVC separation).
We do have repositories. And when joining it could belong to both tables, and thus to both repositories. In those cases the devs picks one: the one that it most prominent to him.
In my experience with fat models is that it works for trivial cases. Once you get more complex business rules that span multiple models, the question becomes which model should it be implemented on. For example in a e-commerce app you might need to evaluate User, Product, DiscountCode and InventoryRow tables as part of a single logical business case to determine the final price. At that point it doesn’t make much sense to implement it on a model since it’s not inherent to any of them, but a PriceCalculator service makes sense.