Architectural Styles Explained in PHP

You can decide on many architectural approaches and styles when starting new PHP application. This will be very superficial overview of different architectures, but it will be enough for you to start thinking about different ways you can structure your application. I picked four to talk about. Three will be in this post and the last one “Command Query Responsibility Segregation” deserves its own post.

One of those four you should never use, let us try and guess which one.

Good Ol’ Days

Yes. You guest it. The good old days architecture is that one that should not be used. Nevertheless it should be mentioned here. This is the old way of writing PHP application. People often call this approach as PHP 4 way of coding. That’s too generous. Because this type of coding is more of PHP 3 style.

You see back then, there were no classes in PHP and separation of concerns were alien concepts among the PHP community.

Let’s see one example of application written this way.

As you can see html and logic is mixed together. We call this “Big Ball Of Mud“.
These days, there are still applications that use this style of coding. One major problem here is also that this uses mysql_real_escape_string to escape parameters, which is proven to be unsafe, so the risk of sql injection is high.

Application like this is the main reason why so many communities look down on PHP and even this is now history. Some developers still use this style of programming when beginning their new projects, which is directly hurting PHP community.

Let’s talk about some newer architecture.

Layered Architecture

This was major improvement because it introduced separation of concerns. As a consequence code became reusable and maintainable.

Rule for layered architecture is that each layer must be tightly coupled with the layers beneath it. What layered architecture tries to solve is problem of mixing different components of an application. To go back to our previous example, blog post view representation should be completely independent of blog post as conceptual entity.

The reason this is good is that blog post as an entity can be visually represented by one or more views, as opposed to being tightly coupled to a specific representation.

We know this type of architecture by more famous title ‘Model-View-Controller Pattern’.

Model manages data and logic for business rules.

Controller job is to organize interactions between other layer and trigger actions on model depending on user inputs and send messages to view in order to refresh the representation.

View has a responsibility to provide visual representation of model and provide a way to trigger changes on Model state.

So now let’s take a look at simple code example extending on our previous code snippet, for this architecture.

Model is now represented by Post and PostRepository. But we have another Post representation. It’s Post service.

Services are when the real magic happens. Its job is to orchestrate the behavior of Post.

As you can see Application services are the ones that make things happen.

View is presented by some of the template languages. The most popular are Twig, Blade, etc… You can represent it by plain php and html. Recommended way is to use some of the languages for that, but it is not vital.

There are some risks when applying this architecture. You can see that in PostRepository we are directly placing infrastructural details. That is violating Separation of Concerns. How to fix that?

Hexagonal Architecture

Hexagonal Architecture (Ports and Adapters) was defined by Alistar Cockburn in his book Hexagonal Architecture. It depicts application as a hexagon, where each side represents a port one or more adapters. Port is a connector with a pluggable adapter that transforms an outside input to something the inside application can understand, and vice-versa. It can also emit message and transform to whatever outside can understand.

This all sounds complicated but let us apply it to our example from before and solve infrastructural details being placed in our model directly and make it more clear that way.

In order to retrieve blog posts from the database, we need a Port in this case that is going to be PostRepository. Remember this is Port because we will need to communicate with outside, in this case it is database.

This interface exposes Port that the application will retrieve information about blog posts through. Now we need adapter for this.

Now our PostService looks like this.

You can see now that we can easily change database without the need to change our model domain. If we decide, we can create RedisPostRepository and just replace it, if we decide to.

This post is being heavily influenced by Domain Driven Design in PHP which is awesome book. You should definitely check it out here.