PHP Enterprise: cómo se escribe código en grandes empresas

Por qué PHP sigue dominando en Enterprise y cómo no quedar mal

Cuando escuchas «PHP», lo primero que viene a la mente es un landing page en una tarde o un blog simple en WordPress. Pero abre las vacantes de grandes bancos, retailers o empresas de telecomunicaciones: hay toneladas de puestos para desarrolladores PHP. Y esto no es de «código rápido y sucio». Esto es PHP Enterprise. Toda una industria con sus propias reglas, patrones arquitectónicos y cultura de code review.

¿En qué se diferencia el desarrollo PHP en una gran empresa de una startup? No solo escribes «código que funciona». Construyes un sistema que debe vivir años, soportar decenas de lanzamientos y resistir la carga de miles de usuarios. En este artículo, analizaré las características clave del desarrollo Enterprise en PHP: desde la arquitectura hasta el deploy. Habrá mucho código, consejos prácticos y mínimo relleno.

Arquitectura: SOLID, capas y nada de magia

En Enterprise, la primera regla es que el código debe ser predecible y fácil de probar. Aquí no vale eso de «aquí metí rápido una consulta directamente en el controlador». En proyectos grandes, debes seguir los principios SOLID y separar claramente las responsabilidades entre capas.

La arquitectura típica de una aplicación Enterprise en PHP se ve así:

\n
• Capa de presentación — controladores, rutas, Middleware.
\n
• Capa de aplicación — servicios, DTO, comandos/manejadores (CQRS).
\n
• Capa de dominio — entidades, Value Objects, repositorios (interfaces).
\n
• Capa de infraestructura — ORM, APIs externas, caché, colas.
\n

Así se ve en la práctica. En lugar de escribir SQL directamente en el controlador:

// ❌ Mal: mezclamos capas\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}

En Enterprise verás algo como esto:

// ✅ Bien: separación de responsabilidades\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}

¿Ves la diferencia? La segunda opción se puede probar, reutilizar y modificar fácilmente. Eso es PHP Enterprise: cuando el código no solo funciona, sino que está diseñado.

Value Objects y tipado estricto

En proyectos grandes, no verás string $email en los parámetros. En su lugar, se usan Value Objects. Es código autodocumentado que protege contra errores en tiempo de compilación.

class Email {\n    public function __construct(private string $value) {\n        if (!filter_var($value, FILTER_VALIDATE_EMAIL)) {\n            throw new \\InvalidArgumentException('Email inválido');\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 $email