The Clean Architecture in php

Organizing the Code
We’ve discussed Entities, Services, Factories, Repository interfaces and concrete Repositories.
Where do we put all this stuff?
It makes sense to logically separate the layers of your application to their own root fielders, even
if the shared parent folder is the same. We have essentially talked about two layers, Domain
and Persistence. So starting there might be a good idea, and then grouping each component type
under those two folders:

---

Database Independence
93
src
/
Domain
/
Entity
/
Factory
/
Repository
/
Service
/
Persistence
/
Repository
/
Following the
PSR-4 autoloading standard²⁸
, we’d also have similar namespaces, for instance:
MyVendor\Project\Domain\Entity\Customer
I’ve taken this one step further in a series of applications that actually share the same Domain
(and ultimately, database). Domain and Persistence have both been broken up into separate code
repositories, all loaded into several parent projects using Composer. It’s the ultimate in separation
of concerns: the code bases are literally separate. Granted, that doesn’t mean they’re decoupled.
How you want to organize your code is up to you. My ultimate recommendation is to keep the
layers segregated out into at least their own folders.
Wrapping it Up
The purpose for taking the database away from being the center of our application is so that we
are no longer dependent and coupled to that database. This gives us the freedom to swap out
database flavors, or even add in a middle layer such as an API in between our application and
the database, without having to rewrite our entire application. It also gives us the flexibility in
switching out database libraries, say going from Doctrine to Laravel’s Eloquent ORM.
We’ll next look at applying some similar principals to the developer’s framework of choice, and
explore how we can limit decoupling in Framework Independence.
²⁸
http://www.php-fig.org/psr/psr-4/

---