Enterprise PHP: How Code is Written in Large Companies

Why PHP Still Rules in Enterprise, and How to Avoid Embarrassing Yourself

When you hear "PHP," the first association is a landing page thrown together in an evening or a simple blog on WordPress. But open the job listings of major banks, retailers, or telecom companies — there are tons of vacancies for PHP developers. And this isn't about "quickly throwing together code." This is Enterprise PHP. An entire industry with its own laws, architectural patterns, and code review culture.

How does PHP development in a large company differ from a startup? You don't just write "working code." You build a system that must live for years, survive dozens of releases, and withstand the load of thousands of users. In this article, I'll break down the key features of Enterprise development in PHP: from architecture to deployment. There will be plenty of code, practical advice, and minimal fluff.

Architecture: SOLID, Layers, and No Magic

In Enterprise, the first rule is that code must be predictable and easily testable. "I'll just quickly whip up a query right in the controller" won't fly here. In large projects, you must follow the SOLID principles and clearly separate responsibilities between layers.

A typical architecture of an Enterprise application in PHP looks like this:

\n
• Presentation layer — controllers, routes, Middleware.
\n
• Application layer — services, DTOs, commands/handlers (CQRS).
\n
• Domain layer — entities, Value Objects, repositories (interfaces).
\n
• Infrastructure layer — ORM, external APIs, cache, queues.
\n

Here's what it looks like in practice. Instead of writing SQL directly in the controller:

// ❌ Bad: mixing layers\nclass OrderController {\n    public function create(Request $request) {\n        $db = new PDO('mysql:...');\n        $db->exec("INSERT INTO orders (user_id, total) VALUES ({$request->get('user_id')}, {$request->get('total')})");\n        return new JsonResponse(['status' => 'ok']);\n    }\n}

In Enterprise, you'll see something like this:

// ✅ Good: separation of concerns\nclass OrderController {\n    public function __construct(\n        private OrderService $orderService\n    ) {}\n\n    public function create(CreateOrderRequest $request): JsonResponse {\n        $dto = new CreateOrderDTO(\n            userId: $request->getUserId(),\n            total: $request->getTotal()\n        );\n\n        $order = $this->orderService->createOrder($dto);\n\n        return new JsonResponse(['id' => $order->getId()]);\n    }\n}\n\nclass OrderService {\n    public function __construct(\n        private OrderRepositoryInterface $orderRepository,\n        private EventDispatcher $eventDispatcher\n    ) {}\n\n    public function createOrder(CreateOrderDTO $dto): Order {\n        $order = new Order($dto->userId, $dto->total);\n        $this->orderRepository->save($order);\n        $this->eventDispatcher->dispatch(new OrderCreatedEvent($order));\n        return $order;\n    }\n}

See the difference? The second option can be tested, reused, and easily modified. That's Enterprise PHP — when code isn't just working, but designed.

Value Objects and Strict Typing

In large projects, you won't see string $email in parameters. Instead, Value Objects are used. This is self-documenting code that protects against errors at compile time.

class Email {\n    public function __construct(private string $value) {\n        if (!filter_var($value, FILTER_VALIDATE_EMAIL)) {\n            throw new \\InvalidArgumentException('Invalid email');\n        }\n    }\n\n    public function getValue(): string {\n        return $this->value;\n    }\n}\n\nclass User {\n    public function __construct(\n        private UserId $id,\n        private Email $emai