This seems to be more like hair-splitting on the below broad setup that I think is fairly commonly followed (atleast in Java CRUD world): 1. A model represents

This seems to be more like hair-splitting on the below broad setup that I think is fairly commonly followed (atleast in Java CRUD world): 1. A model represents a record of a table (or a view). If a validation on a field is as low-level as null/not-null, it is better defined at a database level. Additional business logic related validations (that solely require the properties of the model as input), can be part of the model. 2. A repository provides facilities to interact with the database for either returning or creating instances of model and associated actions. Basically db-related actions live here. 3. A service can provide ways to perform operations related to the model with the help of the repository. E.g. fetch all records with a given area code. 4. For business-logic/workflows that span multiple models, higher-level services can invoke multiple lower-level services to orchestrate the workflow. 5. Controllers host the user-facing request/response related methods that invoked the higher-level services. There can be variations of this with their pros and cons but this approach has worked well for me (mostly using Spring Boot).