CQRS और Event Sourcing PHP में: जटिल प्रोजेक्ट्स के लिए आर्किटेक्चर

जब प्रोजेक्ट बढ़ता है तो सामान्य CRUD काम करना क्यों बंद कर देता है

कल्पना करें: आप PHP में एक ऑनलाइन स्टोर लिख रहे हैं। पहले सब कुछ सरल है — उत्पाद जोड़ा, कीमत बदली, हटाया। लेकिन छह महीने बीत जाते हैं, और नई आवश्यकताएं सामने आती हैं: सभी परिवर्तनों का ऑडिट, किसी विशिष्ट तिथि पर डेटा पुनर्स्थापना, जटिल छूट तर्क। सामान्य CRUD (Create, Read, Update, Delete) टूटने लगता है। डेटाबेस गड़बड़ हो जाता है, और प्रत्येक नए क्लाइंट अनुरोध के लिए आधे सिस्टम को फिर से लिखना पड़ता है।

परिचित लगता है? तो निश्चित रूप से CQRS (Command Query Responsibility Segregation) और Event Sourcing आपके काम आएंगे — दो शक्तिशाली पैटर्न जो डेवलपमेंट के दृष्टिकोण को बदलते हैं। इस लेख में, हम वास्तविक PHP उदाहरणों के साथ उनका विश्लेषण करेंगे, ताकि आप उन्हें अपने प्रोजेक्ट्स में लागू कर सकें।

सरल शब्दों में CQRS और Event Sourcing क्या हैं

CQRS: कमांड और क्वेरी का पृथक्करण

CQRS एक आर्किटेक्चरल पैटर्न है जो संचालन को दो प्रकारों में विभाजित करता है: कमांड (स्थिति बदलते हैं) और क्वेरी (स्थिति पढ़ते हैं)। क्लासिक MVC में, कंट्रोलर और मॉडल दोनों समान संस्थाओं के साथ काम करते हैं। CQRS इन जिम्मेदारियों को अलग करने का सुझाव देता है।

एक पुस्तकालय की कल्पना करें: पुस्तकों को पंजीकृत करने के लिए एक अलग टेबल (कमांड) और पढ़ने के लिए एक अलग टेबल (क्वेरी) है। कोई एक-दूसरे को परेशान नहीं करता, और प्रत्येक अपने कार्य के लिए अनुकूलित है।

Event Sourcing: वर्तमान स्थिति के बजाय परिवर्तनों का इतिहास

Event Sourcing डेटा संग्रहीत करने का एक तरीका है, जहाँ आप किसी वस्तु की वर्तमान स्थिति नहीं, बल्कि उन सभी घटनाओं का क्रम संग्रहीत करते हैं जिन्होंने उस स्थिति को जन्म दिया। एक पंक्ति "ऑर्डर संख्या 123: स्थिति = वितरित" के बजाय, आप संग्रहीत करते हैं: "ऑर्डर बनाया गया → भुगतान किया गया → भेजा गया → वितरित किया गया"।

यह फोटो के बजाय वीडियो रिकॉर्डिंग की तरह है: आप हमेशा पीछे जा सकते हैं और देख सकते हैं कि किसी भी समय क्या हुआ।

PHP में CQRS और Event Sourcing कब लागू करना चाहिए

ये पैटर्न कोई रामबाण नहीं हैं। एक साधारण ब्लॉग के लिए ये अतिरिक्त हैं। लेकिन यहाँ वे परिदृश्य हैं जहाँ ये अपरिहार्य हैं:

\n
• जटिल डोमेन तर्क (वित्त, बुकिंग, लॉजिस्टिक्स)
\n
• ऑडिट आवश्यकताएँ — यह जानना आवश्यक है कि किसने और कब डेटा बदला
\n
• किसी भी तिथि पर स्थिति पुनर्स्थापना
\n
• माइक्रोसर्विस आर्किटेक्चर — सेवाओं के बीच इवेंट आसानी से स्थानांतरित किए जा सकते हैं
\n
• पढ़ने पर उच्च भार — क्वेरी के लिए अनुकूलित एक अलग रीड-मॉडल बनाया जा सकता है
\n

यदि आपका प्रोजेक्ट हजारों ऑर्डर वाला ऑनलाइन स्टोर, CRM सिस्टम या बैंकिंग एप्लिकेशन है — तो CQRS और Event Sourcing निश्चित रूप से आपके काम आएंगे।

PHP में CQRS का व्यावहारिक कार्यान्वयन

चलिए कोड की ओर बढ़ते हैं। हम एक सरल ऑर्डर प्रबंधन प्रणाली लागू करेंगे। CQRS से शुरू करते हैं।

चरण 1: कमांड और क्वेरी परिभाषित करें

कमांड एक DTO (Data Transfer Object) है जिसमें ऑपरेशन करने के लिए सभी डेटा होते हैं। कमांड कभी भी डेटा वापस नहीं करता — केवल स्थिति बदलता है।

<?php\n// src/Application/Command/CreateOrderCommand.php\nnamespace App\\Application\\Command;\n\nclass CreateOrderCommand\n{\n    public function __construct(\n        public readonly string $orderId,\n        public readonly string $customerId,\n        public readonly array $items, // [['productId' => '...', 'quantity' => 2], ...]\n        public readonly \\DateTimeImmutable $createdAt\n    ) {}\n}\n

क्वेरी भी एक DTO है, लेकिन पढ़ने के लिए। इसमें फ़िल्टर हो सकते हैं और डेटा वापस कर सकते हैं।

<?php\n// src/Application/Query/GetOrderQuery.php\nnamespace App\\Application\\Query;\n\nclass GetOrderQuery\n{\n    public function __construct(\n        public readonly string $orderId\n    ) {}\n}\n

चरण 2: कमांड हैंडलर बनाएँ

कमांड हैंडलर एक सेवा है जो व्यावसायिक तर्क निष्पादित करता है। यह कमांड प्राप्त करता है और स्थिति बदलता है।