The Clean Architecture in php

function
(
$id
) {
return
'Viewing User #'
.
$id
;
});
This routing is much simpler and expressive. Any time a URI matching
/users/view/{id}
is hit,
the anonymous function runs and returns
Viewing User #{id}
.

---

MVC, and its Limitations
67
MVC Isn’t Good Enough
The MVC architecture is a great start to building robust and adaptable software, but it isn’t
always enough. With only three layers in which to organize all code, the developer usually ends
up with too many details in one of the layers. It’s fairly presumptuous to think that everything
should be able to fit into three buckets. Either it’s a model, or a view, or a controller. The view is
usually saved from being slaughtered as its role is pretty well defined, so either the controllers
become overwhelmed with business logic, or the model absorbs it all. The community has for
quite some time adopted the mantra of “fat model, skinny controller.”
Obese Models
This “fat model, skinny controller” mantra is all well and good, until the model layer also becomes
the database abstraction and persistence layer, and now the core business logic is tightly coupled
to a data source. It ultimately becomes the obese model approach. This is bad news, as it makes
it difficult for us to swap out that data layer, either the actual database itself or the library that
powers the abstraction of it.
As it doesn’t make any sense to put database configuration and interaction in the view layer,
and it becomes messy and not reusable to place it within controllers, everything related to the
database, querying, and the representation of the database, the model or entity, gets shoved into
the model. However, this tightly coupling of the representative data model to the actual data
source is problematic.
Let’s say, for example, through the first iteration of our application, that we store and retrieve
all of our data from a relational database system. Later down the road, however, our needs and
number of applications might grow, and we might decide to build a web service API to manage
the interaction of data with all the applications. Since we tightly coupled our business logic and
data access together in the form of a model, it becomes difficult to switch over to our API without
having to touch a lot of code. Hopefully we wrote a big test suite to help us.
Maybe instead of switching primary data sources, you simply find a much better database
abstraction library that you want to use. Perhaps it is a well written library that better optimizes
queries, saves resources, executes faster, and is easier to write. These are some great reasons to
switch. However, if you initially went down a path of merging your database implementation
details with your data representation, you might end up having to rewrite the whole entire model
layer just to switch to a better library.
This becomes a clear issue of violating the Single Responsibility Principle.
A nice, clean model might look like this:

---

MVC, and its Limitations
68