Laravel: Service/Repository Pattern and duplicating code - php

Question

In my project I have decided to use the Service Pattern (Possibly with the Repository Pattern) to deal with the business logic in my application. I have for example a Client model which represents a customer and a corresponding ClientService that is responsible for client-specific business logic.
class ClientService extends Service implements ClientServiceContract
{
public function create(array $attributes)
{
// Create a new client...
}
public function doSomethingElse(Client $client)
{
// Do something else
}
}
Say for example I have another service UserService, which is similar to the ClientService above in that it has methods to create and do other things to User models.
Now on my site, imagine that I have a form that someone can fill in to register their interest in becoming a client. In my back end system I would like to create a button that takes a client's interest record ClientInterest and creates a Client, a User, associates the two and finally sends an e-mail to the new user with the details.
Where, when using the service pattern would it be best to put this logic?
I have considered:
Create a service and method ClientInterestService::createClientAndUser(...) which would use the ClientService and UserService classes to create the Client and User instances and then carry out the association before triggering an event which sends the email. This approach means that I'm not duplicating code, however I'm coupling classes together and I'm breaking some SOLID principles. I'm not sure but I have a feeling this wouldn't be great for testing either.
As described above, create a service class and method to carry out the logic, but instead of using the other two services I would write the logic to create the Client and User instances, carry out the association and trigger the event to send the email. This approach feels nicer, my code is more loosely coupled and I'm not breaking any SOLID principles, however, I'm potentially duplicating code.
Simply put the logic that I would have had in ClientInterestService::createClientAndUser(...) in my controller. Doing this would mean that I have business logic in my controller which kind of defeats the point of having services.

Answer 1

I think if you break this down into smaller steps you can achieve DRY architecture. The steps I'm seeing are:
Create Client
Create User
Associate (via pivot table, junction table etc)
Email
To avoid having the dreaded duplicate code you'd create a method around each of these in your service class or classes. You'd then create an action encapsulating all of the steps involved based around these methods.
Don't be scared to implement things outside of your service class - this doesn't mean it is outside of your service layer.
I see registering client interest as an action. You follow synchronous steps to achieve your desired action. So based on methods like creating a user, client etc we can build an action to register client interest, like so:
<?php
class ClientService {
public function addAction(IAction $action)
{
return $action->process();
}
public function createUser() {} // business logic for creating a user.
public function createClient() {} // business logic for creating a client.
public function createAssociation() {} // business logic for creating an association.
}
interface IAction {
public function process();
}
class RegisterClientInterestAction implements IAction {
protected $client;
public function __construct(ClientService $client)
{
$this->client = $client;
}
public function process()
{
$this->createUser()->createClient()->createAssociation();
}
private function createUser() {} // interact with your client service to call the method $client->createUser()
private function createClient() {} // interact with your client service to call the method $client->createClient()
private function createAssociation() {} // interact with your client service to call the method $client->createAssociation()
}
//USAGE
$service = new ClientService;
$results = $service->addAction(new RegisterClientInterestAction($service));
?>
By doing it this way you are able to utilise the createUser etc methods in a new action but without duplicating the code. By having the addAction on the service class you are still executing the business logic inside of your service layer.
If two or more services are required, I'd take a slightly different approach by moving where I would execute the action.
In terms of handling more than one service you can use DI within the constructor of your action.
Like this:
<?php
class Service {
public function addAction(IAction $action)
{
return $action->process();
}
// Other stuff for a base service...
}
class UserService extends Service {
public function createUser() {} // business logic for creating a user.
}
class ClientService extends Service {
public function createClient() {} // business logic for creating a client.
public function createAssociation() {} // business logic for creating an association.
}
interface IAction {
public function process();
}
class RegisterClientInterestAction implements IAction {
protected $client;
protected $service;
public function __construct(ClientService $client, UserService $user)
{
$this->user = $user;
$this->client = $client;
}
public function process()
{
$this->createUser()->createClient()->createAssociation();
}
private function createUser() {} // interact with your user service to call the method $client->createUser()
private function createClient() {} // interact with your client service to call the method $client->createClient()
private function createAssociation() {} // interact with your client service to call the method $client->createAssociation()
}
//USAGE
$service = new Service;
$results = $service->addAction(new RegisterClientInterestAction(new ClientService, new UserService));
?>

Answer 2

What feels best for me is your proposed solution of #2.
What I like to do is build out the two service classes and see what the duplication there is, then refactor/extract any duplication to another class. This way all classes are very testable and you have the least chance of breaking any SOLID principles.