The Clean Architecture in php

Framework Services
Most frameworks provide helpful services to make writing day to day code much easier. These
can include services that run HTTP requests or even do full API calls, components that implement
an OAuth2 client to log in to those APIs, services that generate PDFs or barcodes, send emails,
retrieve emails, etc. While these services provide a quick and fast way to get the job done by
preventing you, the developer, from writing extraneous code, they are also a great place to run
into coupling problems.
How do you run into coupling problems with these components? Simply by using them.
Consider Laravel’s
Mail
facade:
Mail
::
send
(
'emails.hello'
,
$data
,
function
(
$message
) {
$message
->
to
(
'[e-mail]'
,
'You'
)
->
subject
(
'Hello, You!'
);
});
Laravel makes it extremely simply to send emails, but the minute we drop this in a controller
or service, we’re tightly coupling ourselves to Laravel. Remember, our goal with controllers and
services are to have them as small, lightweight, and uncoupled as possible so that we can mitigate
the work needed to migrate that code over to another controller system, should we ever switch
framework or underlying controller/routing mechanism.
How do we solve this? Using the previously discussed
adapter design pattern
, the correct way to
handle these services are to define an interface outlining the functionality that we need, and
writing an adapter that wraps the framework code to implement that interface. Finally, the
adapter should be injected into whatever client object needs it.