Enterprise PHP: बड़ी कंपनियों में कोड कैसे लिखा जाता है

PHP अब भी Enterprise में क्यों राज करता है, और कैसे खुद को साबित करें

जब आप "PHP" सुनते हैं, तो सबसे पहले दिमाग में आता है - एक शाम में बना लैंडिंग पेज या WordPress पर एक साधारण ब्लॉग। लेकिन बड़े बैंकों, रिटेल कंपनियों या टेलीकॉम कंपनियों की नौकरियां खोलें - वहां PHP डेवलपर्स के लिए ढेरों वैकेंसी हैं। और यह "जल्दी से कोड लिखने" के बारे में नहीं है। यह है - Enterprise PHP। एक पूरी इंडस्ट्री जिसके अपने नियम, आर्किटेक्चरल पैटर्न और कोड-रिव्यू की संस्कृति है।

बड़ी कंपनी में PHP डेवलपमेंट स्टार्टअप से कैसे अलग है? आप सिर्फ "काम करने वाला कोड" नहीं लिखते। आप एक ऐसा सिस्टम बना रहे हैं जिसे सालों तक चलना है, दर्जनों रिलीज़ झेलनी हैं, और हजारों यूजर्स का लोड संभालना है। इस आर्टिकल में मैं Enterprise PHP डेवलपमेंट की मुख्य खास बातों को समझाऊंगा: आर्किटेक्चर से लेकर डिप्लॉयमेंट तक। खूब सारा कोड, प्रैक्टिकल टिप्स और बिल्कुल भी बकवास नहीं।

आर्किटेक्चर: SOLID, लेयर्स और कोई जादू नहीं

Enterprise में पहला नियम - कोड प्रेडिक्टेबल और आसानी से टेस्ट करने योग्य होना चाहिए। यहाँ "मैंने कंट्रोलर में ही तुरंत क्वेरी लिख दी" वाला तरीका नहीं चलेगा। बड़े प्रोजेक्ट्स में आपको SOLID सिद्धांतों का पालन करना होगा और लेयर्स के बीच जिम्मेदारी साफ-साफ बांटनी होगी।

Enterprise PHP एप्लिकेशन का एक सामान्य आर्किटेक्चर कुछ इस तरह दिखता है:

\n
• Presentation layer — कंट्रोलर, रूट्स, Middleware.
\n
• Application layer — सर्विसेज, DTO, कमांड/हैंडलर (CQRS).
\n
• Domain layer — एंटिटीज, Value Objects, रिपॉजिटरी (इंटरफेसेस).
\n
• Infrastructure layer — ORM, बाहरी API, कैश, क्यू.
\n

प्रैक्टिकल में यह कैसा दिखता है। कंट्रोलर में सीधे SQL लिखने के बजाय:

// ❌ बुरा: लेयर्स को मिला दिया गया\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}

Enterprise में आप कुछ इस तरह देखेंगे:

// ✅ अच्छा: जिम्मेदारी का बंटवारा\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}

फर्क दिखा? दूसरे विकल्प को टेस्ट किया जा सकता है, दोबारा इस्तेमाल किया जा सकता है और आसानी से बदला जा सकता है। यही है Enterprise PHP — जब कोड सिर्फ काम नहीं करता, बल्कि डिज़ाइन किया गया होता है।

Value Objects और सख्त टाइपिंग

बड़े प्रोजेक्ट्स में आप पैरामीटर में string $email नहीं देखेंगे। इसके बजाय Value Objects का उपयोग होता है। यह सेल्फ-डॉक्यूमेंटिंग कोड है जो कंपाइल टाइम पर ही गलतियों से बचाता है।

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