Skip to content
Davor Minchorov

Building Maintainable PHP Applications: Introduction

Table of Contents:

  1. PHP Skopje Meetup Recording

  1. Introduction

  2. It’s all depends on the context you are in

  3. Under-engineering vs Over-engineering

  4. Accidental vs essential complexity

  5. Framework Coupling vs Framework Decoupling

  6. Thinking data (CRUD) vs thinking business processes (behaviour)

  7. Planning

  8. Architectural Layers

  9. Model-View-Controller

  10. Hexagonal Architecture (Ports And Adapters)

  11. Clean Architecture

  12. Vertical Slices Architecture

  13. Data Transfer Objects

  14. Value Objects

  15. The Repository Pattern

  16. The Decorator Pattern

  17. The Factory Method Pattern (named constructors)

  18. The Factory Pattern

  19. The Command Bus

  20. The Event Bus

  21. The Query Bus

  22. Testing

  23. Tell, Don’t Ask

  24. Immutable Objects

  25. Composition vs Inheritance

  26. S.O.L.I.D.

  27. Dependency Injection vs Service Location

  28. Active Record vs Data Mapper

  29. Test-Driven Development

  30. Behaviour-Driven Development

  31. Domain-Driven Design

  32. Command Query Responsibility Segregation

  33. Event Sourcing

  34. Event Storming

  35. The Aggregate Pattern

  36. Entities

  37. View Model Pattern

  38. Read Model Pattern

  39. Write Model Pattern

  40. The Service Pattern

  41. The Singleton Pattern

  42. The Null Pattern

  43. The Strategy Pattern

  44. (More topics to be added soon)


Over the years, I’ve had a chance to work on different types of projects in my career, from startups that are built from scratch with a small team or alone, scale-ups and enterprise products with 100s of developers and thousands of features spanning over multiple applications (distributed systems) and I’ve noticed that the code becomes very hard to maintain, slow and very hard to work with after a while, regardless of how successful they are.

I’ve mostly worked with Laravel, Symfony and even native PHP and raw SQL at times so I’ve seen code that you wouldn’t want to touch it or work with it ever.

Recently, I heard something along the lines of:

One of the reasons why we rebuilt our product from scratch is because once you onboard bigger clients, you hit bigger problems and most of it comes down to the architecture and code structure, standards that you choose. I didn’t think that the project will be a business when I built it initially. No matter how much make up you put on a pig, it’s still a pig.

and I thought that this perfectly fits with this series of articles so I had to include it.

I’ve learned that maintaining a product is way harder than building it. You can write the code quickly and it will work, it will do the job, it may even help you build a successful business but it will be horrible to maintain it for the long run if the product survives.

Many people are against thinking for the long run whenever they write code and build products, and they have every right to do that, because who knows if the product will survive after the first year or two.

I’ve always been curious how to structure my code, the architecture of it, but I couldn’t figure out why most projects end up in the same state (more or less) after a while.

I wasn’t chasing perfection, but rather I wanted to learn how to become a better software engineer, so that I can design better products for the long term.

After reading a bunch of different discussions, books and discussing with many different people with different experiences, I noticed that there are ways to deal with complex code but it may be completely different and harder to build products that way.

This is because I am not used to writing code or thinking that way. I’ve spent most of my career doing almost the same thing but in the recent years I started exploring and experimenting with some different approaches to building products which will take a long time to get used to.

In this long series of articles I’ll share some of my learnings along the way, even though I know that this may not be for everyone or not everyone will like it but the idea is that people will learn something new from this, even if they never use it in their projects.

The idea is not to bash people’s experiences, ways of writing code but rather compare the good and the bad sides of each approach and learn something new.

Most tutorials, courses, articles, books, academies, colleges, discussions and other forms of learning resources mostly focus on the basics and/or the short term of building products, but they don’t focus on the long term.

This is because it will take years to create such content and/or that type of content is not really applicable for the target audience that wants to learn more about this stuff. It will also take a long time until the person gets to the point where they understand and connect the dots why one way may be better than another one. It also requires experience, people need to go through trial and error for them to understand why software needs to be built differently in order for it to be maintainable.

I want to do something slightly different with this series, to approach software development from a different angle from my experience. I think that this type of content is very rare or hard to find on the internet.

Some topics may contain more theory rather than code but it’s important to read all of the topics so that you can get a better understanding of what’s going on.

Each article will cover one topic at a time, some may be short, some may be longer and more practical with more complex code examples.

The code examples will be using mostly Laravel or Symfony (wherever applicable) but you don’t have to know or use those frameworks in your daily life. I’ll try to explain every step of the way in as much detail as possible or provide resources so that you can learn more about them.

First, I’ll start with simple code examples and later on move on to refactoring more complex code sample(s) from a real world scenario so that you can see the difference, the pros and the cons of each approach.

Let’s discuss these ideas and approaches so that we can learn from each other’s experience, that’s the main goal after all. I am also doing it for my own selfish reasons, to learn and experiment more but you probably knew that already.

Remember, it’s not about perfect code or “my code is better than yours”, but rather how to maintain the code even if that requires more thinking, more files to be created and code to be written.

I also spoke at the first PHP Skopje meetup on the same topic, which was my first ever public speaking experience.