The Clean Architecture in php

Database Independence
Often times when developing an application that uses a database for storage, the database easily
becomes the center and focal point of the application. At first, this makes sense: we’re building
an application on top of the database. Its sole purpose is to display and manipulate that data
stored in the database. Why wouldn’t it be central to the application?
An application where the database becomes the central focal point suffers from a few problems:
1. The code is often littered with database interaction code, often times raw SQL or at least
direct references and instantiation of classes that query the database. If the database, or
database abstraction code, is literally all over the code base, it becomes nearly impossible
to refactor that code without a time consuming effort.
2. Testing this code without using the database because very hard, if not impossible. Testing
using databases is painful: you have to setup a known state for each and every test case as
the code is modifying the contents of the database with each test. This can become slow
to run, and test suites, to be successful and helpful, need to be fast.
So if the database shouldn’t be central to the application, what should take it’s place at the core?
Domain Models
If you paid attention to our previous discussion about the Clean Architecture, you should already
know: the Domain Model is the core of our application, and central to everything else around it.
Everything builds from it. So what is it exactly?
The domain model layer is a collection of classes, each representing a data object relevant to
the system. These classes, called Models or Entities, are simple, plain old PHP objects.
By definition, the domain model layer, being the core of the application, cannot be dependent
upon any other layer or code base (except the underlying language, such as PHP). This layer is
wholly independent of anything. This makes it completely uncoupled, transferable, and quite
easily testable.