CQRS and Event Sourcing in PHP: Architecture for Complex Systems

When Regular CRUD Stops Working: Introduction to CQRS and Event Sourcing

Have you ever faced a situation where your PHP application grew, and grew... and one fine day a regular UserController turned into a 2000-line monster? Sound familiar? Bugs multiply, performance drops, and adding a new feature gives the whole team a nervous tic. Congratulations, you've reached the point where it's time to implement serious architectural patterns.

Today we'll talk about two powerful tools — CQRS (Command Query Responsibility Segregation) and Event Sourcing. Don't be scared by the complex terms. In reality, they are just elegant ways to say: "Let's stop mixing data reading and writing into one pile" and "Let's store not the current state, but the history of changes."

This article is for PHP developers who have already mastered the basics of OOP and want to take their projects to the next level. You will learn how to apply CQRS and Event Sourcing in practice, see real code, and understand when these patterns are truly needed and when it's better to avoid them.

What is CQRS? Separating Commands and Queries

Imagine your code is a restaurant. Usually, a waiter (controller) takes an order (write request), runs to the kitchen (database), prepares the dish (processes data), and immediately serves it (returns a response). Everything is fine while there are 10 people in the restaurant. But when 1000 guests arrive, the kitchen starts to choke.

CQRS (Command Query Responsibility Segregation) proposes to separate responsibilities: some chefs (commands) only cook, other waiters (queries) only serve. Technically, this means you use different models for reading and writing data.

Basic CQRS Implementation in PHP

Let's see how this looks in code. We'll start with a simple example without frameworks to understand the essence.

// Command — a DTO with data for changing state\nclass CreateUserCommand {\n    public function __construct(\n        public readonly string $email,\n        public readonly string $name\n    ) {}\n}\n\n// Command handler — business logic happens here\nclass CreateUserHandler {\n    public function __construct(\n        private UserRepository $repository,\n        private EventDispatcher $dispatcher\n    ) {}\n\n    public function handle(CreateUserCommand $command): void {\n        $user = new User($command->email, $command->name);\n        $this->repository->save($user);\n        $this->dispatcher->dispatch(new UserCreatedEvent($user->getId()));\n    }\n}\n\n// Query — a DTO for retrieving data\nclass GetUserQuery {\n    public function __construct(\n        public readonly int $userId\n    ) {}\n}\n\n// Query handler — read-only, no changes\nclass GetUserHandler {\n    public function __construct(\n        private UserReadRepository $readRepository\n    ) {}\n\n    public function handle(GetUserQuery $query): ?UserDTO {\n        return $this->readRepository->findById($query->userId);\n    }\n}

Notice: we have two different repositories. UserRepository is responsible for writing (can use complex business logic, validation), while UserReadRepository is responsible for reading (can be a simple SQL query or even a denormalized table).

Command Bus

In real projects, commands and queries are sent through a bus — a central dispatcher that finds the appropriate handler itself.

// Simple Command Bus implementation\nclass SimpleCommandBus {\n    public function __construct(\n        private array $handlers = []\n    ) {}\n\n    public function registerHandler(string $commandClass, object $handler): void {\n        $this->handlers[$commandClass] = $handler;\n    }\n\n    public function dispatch(object $command): void {\n        $handler = $this->handlers[$co