The Clean Architecture in php

The User Interface
One of the final and outermost layers of the onion is the User Interface. The UI has nothing
dependent upon it, but is dependent upon every deeper layer of the onion. It requires the
Application Services to give it meaning, which route through the Domain Services to get to
the Domain, our meat and potatoes of our application. The view, at its core, is a representation
of our domain for the user.
It sits on the outside and has nothing dependent upon it. We can refactor and hack it up at will
without consequence. We could try a new templating language, or a new JavaScript framework
every week, and the stability of our core application will not change.
We won’t spend any time in this book specifically talking about the User Interface, but it will be
touched on in
Framework Independence
and during our
Case Study
at the end of the book.
Infrastructure
The infrastructure layer resides in an outer layer of our onion. Its responsibility is of grave
importance: it provides for our domain. It defines where our data comes from and facilities
the retrieving and saving of it to whatever data source it may come from, either Database, Web
Services (APIs) or something else entirely. Those things sit on the outside of the application.
They’re used by the Infrastructure layer, but they aren’t part of our onion. They’re simply data
providers.
The Infrastructure relies on the Domain Services and Domain Model layer as they provide a
contract for how the Infrastructure must work. This is done through interfaces, and we’ll cover
that in the chapters on
Interfaces and Dependency Injection
and
Database Independence
.
The Infrastructure also depends upon the Application Services layer, as it is usually where the
infrastructure is configured and “hooked up” to the domain. It is usually where our configuration
is defined, and where our Dependency Injection Container or Service Locator is setup to provide
services. We’ll see this at work in our
Case Study
at the end of the book.