If you want to follow the SRP (single responsibility principle) your repository shouldn't know about your business logic, it should just be aware how to store / retrieve data. So if you have to switch later from an Eloquent repository to a MongoDb repository or whatever, having your business logic inside service class instead will be far more easy.

#####Controllers These classes do the bare minimum of just taking the input and giving the output received from service classes.

####Repositories These classes are the used to keep storage or external api layer invisible and give an unified api to talk to these services like database, some email provider etc... They don't have any business logic. All they do is create a uniform access path for services. These are helpfull when we change out architecture like switching to some MongoDB orm from MySQL & Eloquent or ditching Postmark for MailGun.

####Services These are classes that contain the domain logic. They do all the heavy lifting of getting request from controllers, interacting with repositories to store or access data from storage.

####Example You want to register a user. These will be the steps :

• Route will catch the POST request and call the controller method.
• Controller will ask a service (here:validation service) like UserRegistrationFormService to validate the form.
• If not verified controller will redirect the user back with errors from the form validation service.
• If verified it will send a request to service like UserCreation to create the user with input.
• UserCreationService service will use repository UserRepositoryInterface (currently resolving to EloquentUserRepository) to create the database record and then fire user.created events for it.
• Then controller will redirect the user to success page.

So, summing up.

Controllers handle listenong to request & redirect or showing views. Repositories are api layers that talk to services giving us a unified api. Services are the brain of application where they interact with all the other components.

It depends how large your application is. If it's very large, then using UserCreator will keep your code dry. If it's medium or small (the business logic is not so complicated), then using the repo itself is good enough.

You should do some research about TableGateway pattern vs ActiveRecord pattern, they will be helpful

@mcraz thanks :) It was really clear no questions left.

bigsinoos said:

@mcraz thanks :) It was really clear no questions left.

Awesome. Also remember what Jeff says "These are just tools in your belt, not mandatory rules". So, it makes you the decision maker on what you want for your application. This was just what the industry follows referring to good design !

Code happy !