PHP Software Architecture Part 2: The Alternatives

Before we go into the refactoring process, let’s first look at the alternatives we already have. We will go through each of them and weigh in their pros and cons. This will help us make a better decision.

This is a Part 2 to my earlier Part 1 on PHP Software Architecture series: https://medium.com/@sameernyaupane/php-software-architecture-part-1-mvc-1c7bf042a695

If you have not read it yet, please do. Now if you are done with that first article, let’s move on! :)

First of all, you may say, why not HMVC/MVVM etc MVC based alternatives? These variations have been discussed in detail by a very smart guy in PHP community, Anthony Ferrara. So I think it is better to just let you go through that article. You can read the article here: https://blog.ircmaxell.com/2014/11/alternatives-to-mvc.html

He makes the point that all of these are just slight variations. That still does not fully solve our problem at hand.

Now let’s move on to some pretty interesting alternatives.

1. BDD and TDD:

BDD stands for Behaviour Driven Development. And TDD stands for Test Driven Development. These are actually not alternatives, even if they are thrown a lot into conversations these days. TDD is a way to write code, irrespective of the architecture we implement. BDD is a variation of TDD with Behavioral approach to it. So these are not going to help us in implementing an architecture style. Although TDD does help set good standards and forces us to move away from the constraints of MVC as the application grows. We can actually follow TDD with implementing any architecture we want. So they go hand in hand instead of as an alternative.

2. DDD :

Another term that we often hear in the PHP community is DDD. DDD stands for Doman Driven Design. It was introduced by Eric Evans in his blue book aka. “Domain-Driven Design: Tackling Complexity in the Heart of Software” which was published in 2003. I had actually given a hard thought to DDD as an alternative. But there are some issues here too. First of all DDD is not by any means an easy undertaking.

Let’s look at the terms that we need to be familiar with and know the relationships between the parts.

DDD Basic Architecture Overview

Wait, we’re not done yet. That was just a simple basic architecture overview.

Here is the full picture.

DDD Full Architecture Diagram

Now we see how hard it is for a beginner to even think about implementing one into a project. Most of us do not have that much of luxury to take time and go slow on projects. Projects often have deadlines and we need to take that into consideration. I also feel that there are too many layers than needed, for a simple jump from a MVC application.

3. Hexagonal Architecture:

Hexagonal Architecture was introduced by Alistair Cockburn (http://alistair.cockburn.us/Hexagonal+architecture).

Hexagonal Architecture

The main principle behind the hexagonal architecture is the adapter pattern. Each external service that wants to connect to the main application has to go through the Adapter. Each adapter confirms to an interface. This makes it easy to swap an implementation or service. Hexagonal is a bit easy, since all we do is Adapters. But one thing I did not like is the layer separation. Cockburn says “ The rule to obey is that code pertaining to the ‘’inside’’ part should not leak into the ‘’outside’’ part.” So thus we can see that he is following the well known rule “Program to an interface, not implementation”. I think this is a bit overkill for most of our projects. Most of the time (99.999%) we are never going to swap our framework nor our core libraries. Don’t get me wrong, Adapters are good, but using them religiously with Interfaces are not a necessity. Another thing that I see lacking in this architecture is the use of Adapters for everything. The layer of separation is not clearly defined for domain/business logic. We do not need Adapters for framework classes that we need to use. Because we trust them enough and the extra layer of added complexity is rarely of any use.

Another thing worthy of mention is that Vaughn Vernon the author of the red book, aka. “Implementing Domain-driven Design”, talks about Hexagonal Architecture in Chapter 4 of the same book. So we can see that DDD can be combined with Hexagonal Architecture in an application. Now talk about the complexity here. One is already tough to implement, let alone two in the same application. ;)

4. Onion Architecture:

Jeffrey Palermo coined the term Onion Architecture in his blog (http://jeffreypalermo.com/blog/the-onion-architecture-part-1/).

Onion Architecture

The architecture relies on Dependency Inversion between layers of applications. I agree with him somewhat on the importance of Dependency Inversion and the use of Interfaces. But I again think it is overkill to do it for all of the layers. Most of the layers do not need to change or swap for pretty much the whole lifetime of an application. This is somewhat related to Hexagonal Architecture, as Jeffrey himself says “ Alistair Cockburn has written a bit about Hexagonal architecture. Hexagonal architecture and Onion Architecture share the following premise: Externalize infrastructure and write adapter code so that the infrastructure does not become tightly coupled.”

5. Clean Architecture

Clean Architecture was introduced by Uncle Bob.

I’m a big fan of Uncle Bob. I really like his SOLID principles. The Clean Architecture is not bad either. But one thing that Uncle Bob says “Frameworks are out there to get you. You should not extend frameworks”. This is only suitable if you are worried about the framework. I can confidently say most people actually do not change frameworks for the lifetime of a project. I like his ViewModel pattern, which is basically a Decorator pattern. It makes it easy to separate logic from views, making views as dumb as possible. I use that in my own architecture. He also uses Interfaces to separate things from web. That is a bit overkill for web applications to be honest. But for applications that interact with web, cli and/or desktop that is a good way to do it.

This Part 2 also got a bit long with all the alternatives we had. So I’ll call this part done. In the next part we will discuss about a simple architecture that I came up with, that you can follow. It is easy to implement and extend. And it basically just extends MVC to make it easier to get started with.

Don’t forget to clap this article! Share if you found it useful and follow for Part 3. Thanks :)

Link to Part 3: https://medium.com/@sameernyaupane/php-software-architecture-part-3-extensible-architecture-c3fc4d8f0e02

DDD images taken from : https://dotnetcodr.com/2015/08/06/domain-driven-design-with-web-api-revisited-part-1-introduction/

Hexagonal Architecture image taken from: http://alistair.cockburn.us/Hexagonal+architecture

Onion Architecture image taken from: http://jeffreypalermo.com/blog/the-onion-architecture-part-1/

Clean Architecture image taken from: https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html