All right. Let’s go over and refactor our code from part one.
Let’s once again look at our FlightController:
First of all let’s move saveData() into a Repository class. It’s easy since all the API related code is in this method. For your own code base, if you do not have a separate method, we would have to do that first. This makes it easier to move it into a different layer.
Now this is our FlightRepository class:
All we did was move the “saveData” method from the controller to its own separate class.
For the “log” method, we will move it into a Service class. This is because we may need to reuse this log functionality in another place too. So it is a wise choice to move it into a Service class.
This is how our FlightLogger Service will look like:
Now, finally we move all our Flight API call logic into an Adapter class.
Note that we are also injecting the FightLogger Service instance to this Flight Adapter. Laravel auto injects dependencies, so we won’t need to inject them manually.
Finally, this is how our Controller looks:
As you can see, we are down to just one method now. Which is much better from our previous four methods for a single functionality. Now there is one more step to make this remaining method lean. Let’s introduce a Domain class to contain the remaining logic.
This is how the Domain class looks like:
Now, let’s refactor our Controller once again.
This is how the FlightController looks:
And, there you go. Our FlightController is very thin. And it does not contain any business/domain logic at all. We moved all our code into different layers. We used Domains, Repositories, Adapters and Services to get to the Extensible Architecture.
I hope you enjoyed the series. Please don’t forget to give some “claps” here on Medium. And please subscribe for future articles.
Happy coding! Cheers :)