The Clean Architecture in php

Independent of Database. You can swap out Oracle or SQL Server, for Mongo,
BigTable, CouchDB, or something else. Your business rules are not bound to the
database.
Independent of any external agency. In fact your business rules simply don’t know
anything at all about the outside world.
Framework Independence
Framework independence is huge. When a developer initially starts using frameworks for their
projects, they might think that the framework is the end game for their application. They make
a choice and they’re sticking with it. But that’s a terrible decision.
Framework’s live and die, and even when they don’t die, they change, leaving the project that
depends on them out in the cold. Take Zend Framework, for example. The release of Zend
²¹
http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html

---

The Clean Architecture
70
Framework 2 was such a massive change and shift, that it was near impossible to upgrade any
ZF1 application to ZF2 without a complete rewrite. Especially if you based your domain around
the
Zend_Model
family of classes.
Not only that, but new frameworks come out all the time. The PHP framework scene is more
active than it has ever been, with previous unknowns like Laravel surging in popularity, and
micro-frameworks, such as Silex, starting to get due respect. The best decision yesterday is not
always the best decision today.
This is why it is the utmost importance to make sure that your applications are written as
framework agnostic as possible. We’ll talk about this in
Framework Independence
Testable
Testability in applications of any size of are of extreme importance. Software tests are the single
most important means to preventing regression errors in an application. To people who sell their
software, regression bugs often mean warranty work and a loss of billable time. And for all
software developers, bugs are simply a pain to deal with, often a pain to troubleshoot and fix,
and, without tests, more often than not a guessing game.
When we write software, we refactor code quite often. In fact, the process of software
development in general can be seen as an endless series of refactoring. As we continually write
code, we’re continually evolving the application, tearing down previous implementations and
replacing them with newer, better ones, or enhancing them to account for some new feature set.
Since we’re always changing what already exists, having a suite of tests that are readily available,
fast to run, and comprehensive becomes very important. It can literally be the difference between
quickly preventing many bugs in the first place and spending hundreds of hours trying to fix
them later.
While this book doesn’t have a dedicated chapter to testing, concepts discussed throughout the
book will often discuss how they help the refactoring and testing process, and why they are good
practices for developing a robust and highly available test suite.