Enterprise PHP: So schreiben große Unternehmen ihren Code

Warum PHP im Enterprise-Bereich immer noch dominiert – und wie Sie dabei glänzen

Wenn man „PHP“ hört, denkt man zuerst an eine schnelle Landingpage oder einen einfachen Blog auf WordPress. Aber schauen Sie sich die Stellenanzeigen großer Banken, Einzelhändler oder Telekommunikationsunternehmen an – dort gibt es unzählige Stellen für PHP-Entwickler. Und dabei geht es nicht um „schnell Code zusammenschustern“. Es geht um Enterprise PHP. Eine ganze Industrie mit eigenen Gesetzen, Architekturmustern und einer Kultur des Code-Reviews.

Was unterscheidet die PHP-Entwicklung in einem großen Unternehmen von der in einem Startup? Sie schreiben nicht einfach „funktionierenden Code“. Sie bauen ein System, das Jahre überdauern, Dutzende von Releases überstehen und die Last von Tausenden von Benutzern bewältigen muss. In diesem Artikel analysiere ich die wichtigsten Besonderheiten der Enterprise-Entwicklung mit PHP: von der Architektur bis zum Deployment. Viel Code, praktische Tipps und wenig Blabla.

Architektur: SOLID, Schichten und keine Magie

Im Enterprise-Umfeld gilt die erste Regel: Code muss vorhersagbar und leicht testbar sein. Hier kommt man nicht mit „Ach, ich baue schnell eine Abfrage direkt im Controller ein“. In großen Projekten müssen Sie die SOLID-Prinzipien befolgen und die Verantwortlichkeiten klar zwischen den Schichten trennen.

Eine typische Architektur einer Enterprise-Anwendung in PHP sieht so aus:

\n
• Presentation Layer – Controller, Routen, Middleware.
\n
• Application Layer – Services, DTOs, Commands/Handler (CQRS).
\n
• Domain Layer – Entitäten, Value Objects, Repository-Schnittstellen.
\n
• Infrastructure Layer – ORM, externe APIs, Cache, Warteschlangen.
\n

So sieht das in der Praxis aus. Anstatt SQL direkt im Controller zu schreiben:

// ❌ Schlecht: Vermischung der Schichten\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}

Im Enterprise-Umfeld sehen Sie eher Folgendes:

// ✅ Gut: Trennung der Verantwortlichkeiten\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}

Sehen Sie den Unterschied? Die zweite Variante ist testbar, wiederverwendbar und leicht änderbar. Das ist Enterprise PHP – Code, der nicht nur funktioniert, sondern durchdacht ist.

Value Objects und strenge Typisierung

In großen Projekten werden Sie kein string $email in den Parametern sehen. Stattdessen werden Value Objects verwendet. Das ist selbst-dokumentierender Code, der bereits zur Kompilierzeit vor Fehlern schützt.

class Email {\n    public function __construct(private string $value) {\n        if (!filter_var($value, FILTER_VALIDATE_EMAIL)) {\n            throw new \\InvalidArgumentException('Ungültige E-Mail-Adresse');\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\n