The Clean Architecture in php

A Sample Domain Model
A sample domain model for a customer might look something like this:

---

Database Independence
85
class
Customer
{
protected
$id
;
protected
$name
;
protected
$creditLimit
;
protected
$status
;
public function
getId
() {
return
$this
->
id
;
}
public function
setId
(
$id
) {
$this
->
id
=
$id
;
return
$this
;
}
public function
getName
() {
return
$this
->
name
;
}
public function
setName
(
$name
) {
$this
->
name
=
$name
;
return
$this
;
}
// ...
}
This Domain Model is a pure PHP object. It has no dependencies nor coupling, other than to
PHP itself. We can use this unhindered in any of our code bases, easily transfer it to other code
bases, extend it with other libraries, and very easily test it.
We’ve achieved some great things following this Domain Model implementation, but it’s only
going to get us so far. Right now, we just have a simple PHP object with some getters and setters.
We can’t do much with that. We’re going to have to expand on it, otherwise it’s going to be
terribly painful to use.
Domain Services
Domain Services, being the next layer in the onion of our architecture, is meant to expand on this
and provide meaning and value to the Domain Model. Following the rule of our architecture,
layers can only have dependency upon layers deeper in the onion than it is. This is why our
Domain Model layer could have no dependencies, and why our Domain Services layer can only
depend upon, or couple to, the Domain Model layer.
The Domain Services layer can consist of several things, but is usually made up of:

---

Database Independence
86
• Repositories, classes that define how entities should be retrieved and persisted back to
some data storage, whether it be a database, API, XML or some other data source. At the
Domain Services layer, these are simply interfaces that define a contract that the actual
storage mechanism must define.
• Factories, are simply classes that take care of the creation of entities. They may contain
complex logic about how entities should be built in certain circumstances.
• Services, are classes that implement logic of things to do with entities. These can be
services such as invoicing or cost buildup or classes that build and calculate relationships
between entities.
All of these are implemented only using the Domain Model and other Domain Services classes.
Again, they have no dependence or coupling to anything else.
Repositories
Repositories are responsible for defining how Domain Model entities should be retrieved from
and persisted to data storage. At the Domain Services layer, these should simply be interfaces that
some other layer will define. Essentially, we’re providing a contract to follow so that other layers
of our application can remain uncoupled to an implementation. This allows that implementation
to be easily changed, either by switching out what is used in production, or maybe just switching
out what storage is used during testing.
A sample repository might look like this: