One thing I truly value in development teams is a solid grasp of design patterns. In my opinion, thorough knowledge of these patterns - and, more importantly, having the insight to pick the right one at the right time, along with other key skills - sets a senior engineer apart from a mid-level one.

When a project starts stretching beyond its original scope, keeping the code from sliding into chaos becomes one of the biggest hurdles. It’s like a town springing up overnight with no planning - streets that lead nowhere, buildings crammed into awkward spaces, and power lines twisted into a messy knot. That’s what an unstructured codebase feels like. Design patterns work as the town’s master plan: they break big problems into smaller, reusable parts, provide tried-and-true solutions for common challenges, and give the team a shared structure to follow. Whether it’s object creation, dependency handling, event wiring, or swapping behaviors on the fly, patterns help the code stay organized, clear, and adaptable as new requirements come in.

Why Design Patterns Matter

Solving recurrent problems with proven solutions - instead of reinventing the wheel, design patterns help address common challenges in everyday software engineering. For example, when dealing with configurable object creation or flexible behavior swapping, patterns like Factory or Strategy can be applied. This allows the focus to remain on delivering features that matter, rather than spending time debugging edge cases or patching the code with quick fixes.

Communication of complex ideas - design patterns are well thought out and documented. Once a team adopts them, they also become a shared vocabulary that speeds up communication, code reviews, and design discussions. A simple statement like “this component is an Observer” instantly conveys intent and structure.

Boost maintainability and readability - following a common structure makes the code instantly recognizable to team members. The intent is clear: factories create, adapters translate, and so on - no guessing required.

Enable scalability and flexibility - requirements change over time. Patterns such as Chain of Responsibility or Strategy allow new behaviors to be added without rewriting existing components. This is especially useful for practical enhancements, like introducing a new payment method or enabling social login.

Promote best practices and consistency - when the team uses a consistent set of solutions, the codebase remains cohesive. Similar problems are solved in similar ways, reducing cognitive load and preventing ad-hoc sprawl. These patterns also encourage principles like SOLID and DRY, which are widely regarded as industry best practices.

Beyond the Usual Suspects – Patterns with Real Impact

Design patterns are all around us - they show up in our favorite libraries and frameworks. I’m not going to cover them at a surface level - there is a lot of content on that topic on the Internet already. Instead, I’ll focus on three patterns that tend to be overlooked but can be incredibly powerful in the right scenarios. All of them are behavioral - how objects talk to each other and how responsibilities are shared between them.

Strategy

Strategy pattern is about putting interchangeable behaviors behind one interface so the code picks the right one based on context or configuration, not a pile of conditionals. It shines in components that enforce logic differing by country, region, or other boundaries. Examples include payment fee and tax calculators per method and country, shipping price algorithms per carrier, discount engines with stackable rules, rate limiting strategies tuned per API client, or export formats like CSV vs JSON. The result is clean extension points, simpler testing, and no more “if method is card and country is CZ then do X” scattered across controllers and services. Here's a code example. Let's say I have a simple API method that calculates a discount based on the provided region:

<?php

namespace App\Controller;

use App\DiscountService\DiscountCalculator;
use App\Enum\Region;
use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\HttpKernel\Attribute\MapQueryParameter;
use Symfony\Component\Routing\Attribute\Route;

final class DiscountController extends AbstractController
{
    public function __construct(
        private readonly DiscountCalculator $discountCalculator,
    ) {
    }

    #[Route('/', name: 'app_discount')]
    public function index(
        #[MapQueryParameter(validationFailedStatusCode: Response::HTTP_UNPROCESSABLE_ENTITY)]
        ?Region $region = null,
        #[MapQueryParameter(validationFailedStatusCode: Response::HTTP_UNPROCESSABLE_ENTITY)]
        float $amount = 0,
    ): Response {
        $response = [
            'region' => $region?->value,
            'discountedAmount' => $amount,
        ];

        if ($region !== null) {
            $response['discountedAmount'] = $this->discountCalculator->calculateDiscount($amount, $region);
        }

        return $this->json($response);
    }
}

The controller simply takes in two arguments - amount and region, passes them to our discountCalculator service and returns a discounted amount.

<?php

namespace App\DiscountService;

use App\Enum\Region;
use Symfony\Component\DependencyInjection\Attribute\AutowireIterator;

final class DiscountCalculator
{
    /**
     * @param DiscountMethodInterface[] $discountMethods
     */
    public function __construct(
        #[AutowireIterator('discount_service.discount_method')]
        private iterable $discountMethods,
    ) {
    }

    public function calculateDiscount(float $total, Region $region): float
    {
        foreach ($this->discountMethods as $discountMethod) {
            if ($discountMethod->canBeDiscounted($region)) {
                $total = $discountMethod->getDiscountedPrice($total);
            }
        }

        return $total;
    }
}

Here’s our calculator - it takes in all the strategies, finds one that can apply the discount, calculates it and returns the value. If no discount method is found, it returns the original value.

<?php

namespace App\DiscountService;

use App\Enum\Region;
use Symfony\Component\DependencyInjection\Attribute\AutoconfigureTag;

#[AutoconfigureTag('discount_service.discount_method')]
interface DiscountMethodInterface
{
    public function canBeDiscounted(Region $region): bool;

    public function getDiscountedPrice(float $originalPrice): float;
}

<?php

namespace App\DiscountService;

use App\Enum\Region;

class EuDiscountMethod implements DiscountMethodInterface
{
    public function canBeDiscounted(Region $region): bool
    {
        return $region === Region::EU;
    }

    public function getDiscountedPrice(float $originalPrice): float
    {
        // In the EU region, we can give a discount of 10%
        return $originalPrice * 0.9;
    }
}

This approach keeps our codebase clean and maintainable - all calculation logic is centralized in one place, and the service is easily extendable. When we need to add a new discount type, we simply create a new class implementing DiscountMethodInterface.

Chain of Responsibility

Chain of Responsibility pattern is about passing a request through a pipeline of handlers where each one decides whether to process it or pass it along. It replaces long if-else chains with small, focused components that can be added, removed, or reordered without breaking everything else. It’s especially useful for workflows where multiple steps may apply conditionally, like processing an incoming HTTP request, sanitizing user input, or running validation rules in sequence. Arguably one the best examples of this pattern is HTTP Request Middleware described in PSR-15. Here's a code example - let's say we're implementing a service that systematically prepares a username from an input string:

<?php

namespace App\UsernameService;

use Symfony\Component\DependencyInjection\Attribute\AutoconfigureTag;

#[AutoconfigureTag(self::TAG_NAME)]
interface UsernameHandlerInterface
{
    public const TAG_NAME = 'username_service.username_handler';

    public function handle(string $username): string;
}

At the beginning, we have a simple interface with an autoconfigured tag and a single method.

<?php

namespace App\UsernameService;

use Symfony\Component\DependencyInjection\Attribute\AsTaggedItem;
use Symfony\Component\String\Slugger\SluggerInterface;

#[AsTaggedItem(UsernameHandlerInterface::TAG_NAME, priority: 3)]
class TrimAndNormalizeSpaces implements UsernameHandlerInterface
{
    public function handle(string $username): string
    {
        $username = trim($username);

        return preg_replace('/\s+/', ' ', $username);
    }
}

#[AsTaggedItem(UsernameHandlerInterface::TAG_NAME, priority: 2)]
class AddTimestamp implements UsernameHandlerInterface
{
    public function handle(string $username): string
    {
        return sprintf('%s %s', $username, time());
    }
}

#[AsTaggedItem(UsernameHandlerInterface::TAG_NAME, priority: 1)]
class Sluggify implements UsernameHandlerInterface
{
    public function __construct(
        private readonly SluggerInterface $slugger,
    ) {
    }

    public function handle(string $username): string
    {
        return (string) $this->slugger->slug($username);
    }
}

Here are three handler implementations - each performs a simple operation on the provided input. The service orchestrating the whole pipeline receives these items in order based on their priority.

<?php

namespace App\UsernameService;

use Symfony\Component\DependencyInjection\Attribute\AutowireIterator;

final class UsernameProcessor
{
    /**
     * @param UsernameHandlerInterface[] $handlers
     */
    public function __construct(
        #[AutowireIterator(UsernameHandlerInterface::TAG_NAME, defaultPriorityMethod: 'priority')]
        private readonly iterable $handlers,
    ) {
    }

    public function process(string $username): string
    {
        foreach ($this->handlers as $handler) {
            $username = $handler->handle($username);
        }

        return $username;
    }
}

Here's the final processor that ties it all together.

Specification

Specification pattern is about capturing business rules as small, reusable objects that can be combined into more complex conditions. Instead of scattering if statements all over the code, each rule lives in its own class with a clear isSatisfiedBy() method. These rules can then be chained together with logical operators like AND, OR, and NOT to build richer conditions on the fly. It shines in places where logic changes often or needs to be reused in multiple contexts. Examples: filtering candidates in recruitment software based on certifications and location, defining access control rules beyond simple roles, or building query filters that can be applied both in memory and in a database query. The beauty of this pattern is that the same specification can validate a single object in PHP or generate the right conditions for a Doctrine query – meaning the rules are defined once and enforced everywhere, without duplication or risk of divergence.

Here's a code example. Let's say we have an Item object with various properties:

<?php

namespace App\ItemSpecification\DTO;

final readonly class Item
{
    public function __construct(
        public string $name,
        public string $category,
        public float $price,
        public bool $onSale,
        public int $stock
    ) {
    }
}

Next, we need to establish centralized business rules for filtering these items. All these rules implement a common interface:

<?php

namespace App\ItemSpecification;

use App\ItemSpecification\DTO\Item;

interface SpecificationInterface
{
    public function isSatisfiedBy(Item $item): bool;
}

Below are examples of how these rules might be implemented:

<?php

namespace App\ItemSpecification;

use App\ItemSpecification\DTO\Item;

final class IsOnSale implements SpecificationInterface
{
    public function isSatisfiedBy(Item $item): bool
    {
        return $item->onSale;
    }
}

final class CategoryIs implements SpecificationInterface
{
    public function __construct(private string $category) {}

    public function isSatisfiedBy(Item $item): bool
    {
        return $item->category === $this->category;
    }
}

final class PriceBetween implements SpecificationInterface
{
    public function __construct(private float $min, private float $max) {}

    public function isSatisfiedBy(Item $item): bool
    {
        return $item->price >= $this->min && $item->price <= $this->max;
    }
}

Logical operators are also implementations of SpecificationInterface:

<?php

namespace App\ItemSpecification;

use App\ItemSpecification\DTO\Item;

final class AndSpecification implements SpecificationInterface
{
    public function __construct(private SpecificationInterface $left, private SpecificationInterface $right) {}

    public function isSatisfiedBy(Item $item): bool
    {
        return $this->left->isSatisfiedBy($item) && $this->right->isSatisfiedBy($item);
    }
}

Now, let's put it all together. Imagine we have a list of items and want to filter them based on a specific set of criteria:

<?php

namespace App\Controller;

use App\ItemSpecification\AndSpecification;
use App\ItemSpecification\CategoryIs;
use App\ItemSpecification\IsOnSale;
use App\ItemSpecification\PriceBetween;
use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\Routing\Attribute\Route;
use App\ItemSpecification\DTO\Item;

final class ItemController extends AbstractController
{
    #[Route('/items', name: 'app_items')]
    public function index(): Response
    {
        $items = [
            new Item('Laptop', 'electronics', 1500, true, 5),
            new Item('Desk Lamp', 'home', 40, false, 10),
            new Item('Smartphone', 'electronics', 900, true, 0),
            new Item('Headphones', 'electronics', 120, true, 15),
        ];

        $spec = new AndSpecification(
            new CategoryIs('electronics'),
            new AndSpecification(
                new PriceBetween(100, 2000),
                new IsOnSale(),
            )
        );

        return $this->json(
            array_values(
                array_filter(
                    $items, 
                    static fn(Item $i) => $spec->isSatisfiedBy($i)
                )
            )
        );
    }
}

Wrapping It Up

Design patterns aren’t silver bullets, but when used with care they are one of the best tools we have to handle complexity in code. They help tame growing projects, make intent explicit, and keep the structure predictable as new requirements arrive. The patterns I highlighted - Strategy, Chain of Responsibility, and Specification - are not always the first ones developers reach for, yet they can quietly transform a codebase when applied to the right problems.

The moral of the story is simple: patterns are not academic exercises. They’re practical building blocks that let us write software that’s easier to extend, test, and reason about. If a team shares this mindset, the difference between “it works for now” and “it will keep working tomorrow” becomes clear.

And of course, these three are just a glimpse. There are plenty of other patterns worth knowing - not only behavioral ones, but also structural and creational. From factories and builders to adapters and decorators, each has its place. The more tools we have in our toolbox, the more likely we are to pick the right one at the right time - and that’s what makes design patterns such a powerful ally in software development.