The Clean Architecture in php

Your Decoupling Toolbox
We’ve uncovered various ways in which poor design decisions can lead to code that is hard to
maintain, hard to refactor, and hard to test. Now we’re going to look at some guiding principles
and design patterns that will help us alleviate these problems and help us write better code. Later,
when we talk about architecture, we’ll apply these principles further to discover how to create
truly uncoupled, refactorable, and easily testable code.

---

Design Patterns, A Primer
A design pattern is a specific solution to a commonly occurring problem in software develop-
ment. These design patterns form a common language among software developers that can be
used to discuss problems and describe solutions. They are transferable across languages and are
not specific to PHP.
Design patterns as we know them today are heavily influenced by “the Gang of Four” who were
instrumental in their popularization starting in 1994 with their book Design Patterns: Elements of
Reusable Object-Oriented Software. The GoF are: Erich Gamma, Richard Helm, Ralph Johnson,
and John Vlissides.
In their book, the GoF described twenty three design patterns organized into three categories:
Creational, Structural, and Behavioral. It would be impossible to cover all of these patterns in
any detail in this book, however, as they are instrumental to nearly every chapter that follows,
we’re going to briefly cover a few of them here.
1. Factory: An object responsible for instantiating other objects
2. Repository: Not actually a GoF design pattern, this is an object responsible for transition-
ing data to and from its storage
3. Adapter: An object that encapsulates another object to make it conform to a desired API
4. Strategy: Encapsulates a behavior or a set of behaviors, allowing them to be used
interchangeably
For a lighter, and maybe funner approach to design patterns, you can also checkout
Head First
Design Patterns⁵
by Freeman, Bates, Sierra, and Robson.